(old)Puppy Linux Discussion Forum

Thanks Billtoo, so these works in Slacko then.
There is a thread for XFE but maybe that one is for Lupu
so we need one XFE thread for each puppy

I have not get motivated to change over to Slacko.
I am still using Lupu out of habit. And this is even ThinSlacko.

I love choice so all power to the Devs for allowing choice.
But I do feel a bit lost not being able to decide which Puppy is best.
Oh the joy of choice.

99 Mbyte is a major achievement.

These small iso's are (appart from the achievement itself) only usefull for the people with small memory footprints. In other words the older PC's, with slower processors.

Would it be smart to use a different compression to the benefit of these slower processors (and end up with a 101Mbyte iso ??).

Just a thought ?

..useful for ... small memory footprints. .. older PC's, with slower processors.

Not necessarily. There are many reasons for developing very low resource distros, hence SliTaz and Tiny Core, inter alia. Of course, there is greater benefit if they can run on old AND new kit, but driver/driver availability might become limiting with, esp. new and voracious video cards, for example. One key to universality is to select a low resource browser and there has been much discussion of this here for many years.
Only for the very smartest developers will there be the prospect of a universal fastboot distro written in assembler and running off a single FDD. So far only the one exists. In the UK, the introduction of the RPi was intended to promote code-level (specifically NOT C/C+/C++ and other picture-based languages) interest and teaching amongst children. We shall see! First get your Pi delivered...

Like most of the latest puppy versions, it fails to offer
the i810 graphics driver in xorg setup; making it a poor
choice for the many fine laptops that have 855gm graphics.

Thanks for this. I hadn't noticed it before! I use Slacko PAE all the time on my desktop, but have tended to go for Racy on my (aging) laptop. I've just installed this on said laptop in order to take advantage of the working X11 grab / ffmpeg in Slacko. Brilliant.
mark

antiloquax wrote:Thanks for this. I hadn't noticed it before!

Ooooo! This may be exactly what I am looking for. My needs are a slim OS that can run:

a web browser with Adobe Flash Player 10.x
putty
the latest TeamViewer (may require igluders run as root .pet)

Lean and mean is all I need.

System:
MiniPC w/N270 (single core) Atom 2Gig Ram.

I see forum member Speedyluck has compiled a Precise for ATOM but does it matter with a single core?

Is THINSlacko a good candidate for this request or can you suggest something that may fit better?

JW

Nice work Micko,
I just installed ThinSlacko to a usb stick for booting my work netbook when I don't feel like using the default WinXP install. The netbook is an Acer eMachines e350-21G16i aka:"model NAV51" (1.6Ghz N450 single core, 1Gb ram)

Running really nicely, and detects both network interfaces properly (including the wireless Broadcom BCM4313).
Device screenshot attached.

Just noticed a problem with sound when using ThinSlacko on the aforementioned netbook -
EDIT - Seems to not really be anything to do with ThinSlacko - probably just a peculiarity of my netbook. But I will leave the info here for now anyway...
when I play youtube vids the sound is fine, with good volume, and if I play mp3s from a usb stick the sound is also fine, but if I then use mhWaveEdit to record a wav from the inbuilt microphone I can see the waveform recorded correctly, but when I try to play it back (either in mhwaveedit or pmusic) there seems to be no sound at all.

Just tried this a second time and the recorded waveform looks very strong (even clipping strongly when I raise my voice), but is only audible when the clipping is strongest - and then only just audible if I have my ear right next to the speaker.

The mic meters seem really sensitive, moving in unison with even quiet sounds, so it seems that the mic is working correctly, but maybe mhwaveedit is not processing the wav correctly? I get the same result if I try to record mp3 - I can see mhwavedit processing the wav into mp3 at save time, but the outcome is a file that is barely audible at all, except for some very low amplitude "alien" squeakings.

All mixer settings seem as I would expect, so not sure what else to look at...

EDIT:I installed Audacity to compare the outcome, and it has the same issue as mhWaveEdit. I did get a message that Audacity had a couple of missing libraries (see pic) so maybe that is a clue..

Any suggestions for the best place to find/put these libraries?

After further testing I don't believe my audio recording problem is anything to do with Thin Slacko (unless it is something to do with a bad lib or something similar). I have the same symptom if I test it with Saluki, and also with Linux Mint (although it is fine using Windows XP which is the native OS on this netbook)

The weird thing is that the recorded track which will not play back through the netbook speakers WILL play back through the headphones - and it is nothing to do with mixer settings as a similar file recorded on a Tosh laptop plays fine through both the headphones and speakers on the netbook.

Anyway, sorry for thinking it might have been Thin Slacko!

If anyone has a similar problem I am documenting it a bit further at:
http://www.murga-linux.com/puppy/viewto ... 220#648220

It could be me doing something wrong or
can it be that one need to add something like

pwait=5 for it to boot on slow cheap USB.
I installed ThinSlacko on two USB for to have
as rescue OS in case the HD breaks down on old Computer.

One of the usb booted but not the other. Same code. The error code it gave where that it could not find
puppy_slacko_5.3.3t.sfs

But when look it is there in the folder so very odd. error?

should I tell it that it is usb in a particular way maybe?
root=(hd0,0) maybe should be root=(hd1,0) or root=(hd0,1)

Nooby - what method did you use to do the install, and what type/number of partitions did you use?

I have found that the mbr on different usb sticks can be different when you buy them from the shop and this affects the way they boot.

My recommendation is that you backup any vital data on that usb stick and then try this:

Boot a machine from a puppy 4.3.1 Live CD (type pfix=ram at the boot prompt).
Run Gparted and clean out the usb stick you are having problems with, and just make it one FAT32 partition (just for testing purposes anyway...). Set the boot flag for that partition to "on" before you exit Gparted.
Do a frugal install of 4.3.1 and see if that stick now boots.

(there are a whole lot of ways to get around this problem, or work out why it is happening, but I just use puppy 4.3.1 when I am having trouble with a usb stick - there is something "magic" about the way Gparted and syslinux work together in the 4.3.1 install routine)

As far as I remember I let it be the Fat32
as it had been from factory and then I did a totally manual
frugal install of Thinslacko moving the files from the iso.

But I am unsure of where I get the gldr and sometimes
I wonder if Geany add some different sign that are invisible
for us humans but are seen by the computer at boot.

Because the menu.lst looks the same but it boots
on one and not the other.

So you don't think I need to add some delay for the USB flash
to stabilize the address something.

puppy 431 is too old for me. Would not Lupu 528-005 work as well?

nooby wrote: sometimes
I wonder if Geany add some different sign that are invisible
for us humans but are seen by the computer at boot.
Because the menu.lst looks the same but it boots
on one and not the other.

The invisible differences are inside the "mbr" (master boot record). Different sticks can have different mbrs when they come out of the shop. This can affect the boot behaviour. Puppy installer does not fix up the mbr unless you specifically tell it to do that (and some puppies do it better than others - it depends on the differences between sticks)

So you don't think I need to add some delay for the USB flash
to stabilize the address something.

Not until after you have tried the puppy 431 trick. If the 431 trick does not work then you can try other things.

puppy 431 is too old for me. Would not Lupu 528-005 work as well?

No. Not for preparing the usb stick. The best idea is that you "prepare" the stick by booting puppy431 into ram, using gparted to clear the partition, doing a puppy431 "universal" install, then if that boots ok you remove the 431 files and replace them with the Lupu or similar files. (but leaving the pup431 mbr in place)

Other people will be able to tell you other methods to achieve the same thing but this is the method that has worked best for me. I spent months fighting similar problems and the most reliable method by far was to prepare the stick with puppy431, then replace the 3 pup files with the files from your preferred puppy (in this case ThinSlacko)

Thanks then I should do as you told me.
Much appreciated you took time to describe it
that detailed.

The script that shuts down the computer when you click menu, shutdown, power off computer is apparently found at /etc/rc.d/rc.shutdown. I want to modify that file in my frugal ThinSlacko install, so I tried clicking on that file to prove it was the right one I need to modify.

The system did not shut down correctly, so that suggests that this script is not the only one that is involved in the shutdown.

I think there might be some other script that gets called first, and does things like unmounting or shutting down x in a way that is beyond the scope of the rc.shutdown script.

Does anyone have any pointers about what runs before rc.shutdown please?

Hi, greengeek.

I believe there are "wmpoweroff" and "wmreboot" files in /usr/sbin that are activated when you click on menu items "reboot computer" or !shutdown computer". Maybe search for them with pfind (it's not fresh in my memory where they are).

I believe those files do some preliminary "closing" of Puppy stuff and then relay to the /etc/rc.shutdown script.

TWYL.

musher0 wrote:I believe those files do some preliminary "closing" of Puppy stuff and then relay to the /etc/rc.shutdown script.

Thanks Musher0, looks like wmpoweroff is the one I need. It seems to be located at /usr/bin/wmpoweroff. Looks like it writes to /tmp/wmexitmode.txt then links to /usr/sbin/shutdownconfig, which writes to /tmp/shutdown_results which is read after control passes back to /usr/bin/xwin which calls /sbin/poweroff which calls /etc/rc.d/rc.shutdown. Darn it - It looks circular and complex. Maybe I shouldn't fiddle with it.

greengeek

What exactly do you want to do? It might be acheivable with a service script which are called with the "stop" parameter from /etc/rc.d/rc.shutdown. A lot easier than fiddling ..

Jasper wrote:

I always make a visual comparison when checking MD5 sums, but, in case it may be of some general interest, perhaps there is an automated method?

Jasper, open a terminal in the directory that has the ISO.
Then type md5sum -c [name of the md5 checksum file]

You will be prompted if the files check OK.

01micko wrote:What exactly do you want to do? It might be acheivable with a service script which are called with the "stop" parameter from /etc/rc.d/rc.shutdown. A lot easier than fiddling ..

I use ThinSlacko in a "dualboot from usb" environment on the Win XP netbook that I use for work, and I'm experimenting with ways of speeding up my day by avoiding having to wait for slow shutdowns caused by slow savefile writes to usb. I think I have found one good solution here:
http://www.murga-linux.com/puppy/viewtopic.php?t=67084
but I realised I needed to be careful not to jeopardise mounted filesystems (especially my NTFS XP stuff) so I was experimenting with ways of doing a normal "proper" shutdown but without letting snapmergepuppy do it's thing. I read the posts about commenting out the snapmergepuppy lines in rc.shutdown but that became an "all or nothing" solution which took away the "automatic save at shutdown" feature completely.
I wanted to allow shutdown saves 90% of the time, but have a desktop icon for "dump_everything_and_shutdown_superquick" for the other 10% of the time.

(I have also trialled the code that inserts a gtkdialog into the shutdown process, and that works fine as long as I am watching the screen during the shutdown, but I was hoping to find a method that is just "click and run - no questions asked")

I toyed with the idea of having two versions of rc.shutdown - one unmodified, and one modified by removal of snapmergepuppy, but then discovered it wasn't as simple as using a desktop icon to call the modified version. The other processes that exist between calling wmpoweroff and handing control to rc.shutdown make it more complex than I first realised.
I've thought of writing a script to rename my proposed "rc.shutdownMODIFIED" to rc.shutdown, then including a routine to rename things back to how they were - but I have some research to do before I'm going to risk it.