(old)Puppy Linux Discussion Forum

Scottish Deerhound, purebred. Adorable, great personality, not afraid of loud noise (lotta people out here think that accelerating poisonous metals to high speed using noisy, explosive materials is a good bit of fun), maybe a little outgoing... housetrained is a must...

...

...oh, you meant Puppy Linux, the software, not Puppy, the group of cute animals that I wish I had more of in my house...

sorry folks, couldn't resist.

I believe an incredibly useful browser for Puppy would be modeled on the mobile browsers currently running on Android. It would primarily utilize mobile websites rather than traditional websites, making it more useful for low-bandwidth locations.

Rationale: Travel for 1 hour outside of any American city on its Interstate Highway, get off of the Interstate and turn at right angles to it, then travel for 20 miles. You are now in a "no-broadband available area" (unless you have re-entered another city). The only available Internet connection will be dial-up or cellular at dial-up speeds. There may be exceptions to this rule along the immediate East and West Coasts of the U.S., but you get the idea. Vast swaths of areas with 1960's fax-machine connection speeds.

By utilizing mobile websites, much of the content-strangling advertising that makes traditional websites unusable in low-bandwidth areas could be avoided. "What about pop-up blockers and anti-advertising software?", I hear you say. Many of the traditional websites are purposely designed to be inoperative unless you enable their advertising content, which prevents you from loading the content you are interested in. The content you are interested in is always last to load, and if the advertising can't load because of low connection speed you never see your desired content.

Mobile browsers have already addressed these concerns and so would be a useful Puppy addition for low-bandwidth users.

MoebusNet, good idea - copied to Saluki thread, for consideration by the fast team...

Aitch

MoebusNet wrote:I believe an incredibly useful browser for Puppy would be modeled on the mobile browsers currently running on Android. It would primarily utilize mobile websites rather than traditional websites, making it more useful for low-bandwidth locations.

Rationale: Travel for 1 hour outside of any American city on its Interstate Highway, get off of the Interstate and turn at right angles to it, then travel for 20 miles. You are now in a "no-broadband available area" (unless you have re-entered another city). The only available Internet connection will be dial-up or cellular at dial-up speeds. There may be exceptions to this rule along the immediate East and West Coasts of the U.S., but you get the idea. Vast swaths of areas with 1960's fax-machine connection speeds.

By utilizing mobile websites, much of the content-strangling advertising that makes traditional websites unusable in low-bandwidth areas could be avoided. "What about pop-up blockers and anti-advertising software?", I hear you say. Many of the traditional websites are purposely designed to be inoperative unless you enable their advertising content, which prevents you from loading the content you are interested in. The content you are interested in is always last to load, and if the advertising can't load because of low connection speed you never see your desired content.

Mobile browsers have already addressed these concerns and so would be a useful Puppy addition for low-bandwidth users.

operamini on puppy and pussy has been done. Search the forum. Cant remember if it does what you want though.
Opera normal with turbo enabled has some speed enhancements.

jpeps wrote:

MoebusNet wrote:"Safely remove usb drive". Powers down thumb drive prior to unplugging ala Ubuntu.

Just unmount it. In slacko, you can just click on the desktop icon. Can't get much easier than that.

Sorry to respond in such a late fashion:

Unmounting a flash drive does indeed protect the Operating System from corruption caused by incomplete data transfers. However, if the flash drive is still receiving power from the USB port, it may be possible to corrupt the data on the flash drive due to voltage fluctuations during the unplugging process. At the very least it would seem to be a best practice to make sure that the USB port is unpowered prior to unplugging, just as it is best practice to utilize the shutdown menu rather than just unplugging your PC to shut off.

I am not an expert by any means and my opinion about the necessity of powering-down a USB flash drive may be completely erroneous. But I do think it unlikely that MS & Ubuntu both wrote code to power-down a flash drive prior to removal if that is unnecessary.

All I can say is, I've been yanking USB flash drives out of my computers for years without powering anything down. So far, no problems that I'm aware of.

I've learned the hard way to equalize the static voltage between a USB flash drive and the computer before I plug the flash drive into the USB socket. To do that, I hold the flash drive by its metal part while touching the metal that surrounds the USB port on the computer with my finger, providing a high-impedance connection across which the static voltage equalizes. If I don't do that, sometimes the computer will reboot when I plug a flash drive into a USB port. I have two computers with Gigabyte motherboards and both of them have rebooted when I plugged in a USB flash drive without first equalizing the static voltage. However, this has not apparently caused any damage either to the motherboard or to the flash drive, only the loss of whatever was in RAM when the computer unexpectedly rebooted.

Belt AND braces...

http://elliotli.blogspot.com/2009/01/sa ... linux.html

Aitch

Hi All
Having Puppies that are made from other linux distributions is
the best thing since sliced bread.
The last time I tried Puppy was years ago. I do not remember the version
number.
Back then the only way to easily add software to Puppy was to use
sfs and pets.

That worked real well unless of course the pet or sfs for the software you wanted
to add did not exist.

Being able to use the Ubuntu repositories such as you are able to in
Puppy Lucid 5.2.8 is wonderful.

Since Lucid is based on Ubuntu Lucid and since Ubuntu has apt-get
I would like apt-get added to the next release of Puppy Lucid.

For those of us who do not want to wait for the Ubuntu
repositories to be updated with the latest software version for the software
we want to install we would be able to compile the latest version from
the authors provided source code.

Yes I have installed dev-x sfs. Yes I can compile the authors source code.
What I cannot do easily is down load, compile and install all the
dependency files.

Yes I have tried to down load the dependency files. The problem I ran
into is that the software I wanted to install had so many dependencies
it would have been ridiculous to try to install the dependencies with out
apt-get.

Yes I know about Pus**y Linux.
But I like Puppy better,

Thank you for your time in reading this Message.

1) Have a way to create partitions (using Gparted or other utility) that emulate a cd-dvd reader/writer. Is that what Windows' Alcohol 120% does? Don't know if it's possible. I tried using that program but I didn't find a way to make my PC recognize this emulated driver from setup.

2) if using a multisession CD to boot, have a way to read/write more .sfs and .2fs files on it after running the CD for the first time. Or songs... whatever. Doesn't it look a waste of CD space when only using it in a 10 or 20% of its surface?

Yes, we would like PPA supports for Ubuntu, Debian, Slack, etc compatible Puppys. Now, most of programs come with only ppa repo.

( and we want also faster Puppy mirrors, longer life, free wifi, etc )

Packetteer wrote:Hi All
Having Puppies that are made from other linux distributions is
the best thing since sliced bread.
The last time I tried Puppy was years ago. I do not remember the version
number.
Back then the only way to easily add software to Puppy was to use
sfs and pets.

That worked real well unless of course the pet or sfs for the software you wanted
to add did not exist.

Being able to use the Ubuntu repositories such as you are able to in
Puppy Lucid 5.2.8 is wonderful.

Since Lucid is based on Ubuntu Lucid and since Ubuntu has apt-get
I would like apt-get added to the next release of Puppy Lucid.

For those of us who do not want to wait for the Ubuntu
repositories to be updated with the latest software version for the software
we want to install we would be able to compile the latest version from
the authors provided source code.

Yes I have installed dev-x sfs. Yes I can compile the authors source code.
What I cannot do easily is down load, compile and install all the
dependency files.

Yes I have tried to down load the dependency files. The problem I ran
into is that the software I wanted to install had so many dependencies
it would have been ridiculous to try to install the dependencies with out
apt-get.

Yes I know about Pus**y Linux.
But I like Puppy better,

Thank you for your time in reading this Message.

re: apt-get for lucid

hello... just letting you know that i made an apt-get solution for lucid and while initially it sounds like a good idea, its not
ultimately its a fail, unless your are just installing leafpad or a game or something.

the problem is that puppy lucid isnt ubuntu its still a puppy with puppy custom scripts and a completely different kernel to ubuntu. The apt-get system overwrites puppies custom scripts with standard ubuntu ones, so in effect if you apt-get install mplayer or vlc or something like that, yeah it installs.... then puppy freezes and then it wont boot as the puppy scripts have been overwritten. The apt-get system itself installs things etc and updates all the scripts etc the program you are install needs, yes... it updates them, cleans all the *crap* out of the custom puppy scripts and adds entries for normal, standard ubuntu. im not saying that puppy scripts are crap, im saying that the apt-get system bleaches all the puppy stuff out of the scripts and replaces it with ubuntu things.

i personally stayed up for 36 hours and typed out 4000 lines of code manually with my actual fingers to create the apt-get status file, i listed all the puppy packages with their correct version numbers so that apt-get knew what to install and what not to install because its already there.
I really did try to make the project work and there was a lot of buzz about it but it was ultimately a fail in the worst way, causing puppy not to boot.

not meaning to discourage you but ive been there, done that and i dont want other people wasting their hard earned free time.

the lesson to be learned if there is one about this subject is that puppy is bleeding edge and leet and custom and small and the kernel is stripped of everything that doesnt absolutely need to be there. This means that no repo from the main distros and a rigged up package manager to accesses them will actually work 100% of the time. Yes some small packages work, but there is the real risk of installing something that simply causes puppy not to boot. The problem is that puppy doesnt run a standard kernel and no mainstream repo will work very well.

the only way to have ultimate compatibility with a mainstream distros repo is to use their distro as a base for your OS and this will result in an OS that is similar to puppy in a lot of ways but is ultimately not puppy and is 200mb larger in size and not as polished, but you can apt-get stuff and it will work. There is ALOT of work and i mean lots and lots to take an existing OS and make it like puppy.... it cant be done, it will be something else.

puppy sacrifices compatibility with alot of mainstream packages in favour of a small and awesome desktop experience.

Can puppy people make their own repo as good as ubuntu or debian? No this will never happen very soon as it would take 99999999999 hours to do, if an extra 250,000 devs jumped in and made the repo then maybe it would be as good.

in the mean time most commonly used packages are available for puppy at the time the version of puppy is released. Puppy is forever growing and changing and this means that the repos need updating constantly.
i think its just a matter of time.... in the future im sure there will be so many people running puppy and developing for it that it will have a repo similar to debian or whatever... we just need to be patient and water our puppys and let them grow

sickgut wrote:i think its just a matter of time.... in the future im sure there will be so many people running puppy and developing for it that it will have a repo similar to debian or whatever... we just need to be patient and water our puppys and let them grow

Yes, I think it would be great to see Puppy retain it's own distinct flavour and benefits so that it attracts solid support from believers, rather than trying to appeal to the masses.

To that end, I would like to see Puppy come with a video format that can compete with Flash (it probably already does but I just don't know about it..) and I'd like to see a webhost somewhere that provided an alternative to youtube - all based on Puppy's own video format. Imaging how good it would be to see all the vids uploaded by fellow puppians.

Imagine if all those leaving school and going to Tech could be encouraged to use "Puptube" as a vector for their own vids. No more flash "upgrades" every five minutes. No more bans on saving vids from the net. Opensource fun not dependent on corporates. I guess it would have to be a paid service - but if it put control back in the hands of the user it might be popular.

I am keen for Puppy to have it's own turf.

Currently the 2fs 'heavy' encrypion is a 128aes encryption. I wonder if that isn't a bit weak nowadays? A tool like pupcrypt offers 2040aes...

pupsaveconfig-2.2.2.pet: 66 K
'save' 'nosave' question at shutdown
xvidcap-1.1.7.pet: 3238 K
xvidcap-1.1.6-i486.pet: 1557 K
from russian Puppyrus repository ( and only this one)
Screen video capture

Pls can you include them all the time in as distro ?

Each and every Puppy Linux should include a Full Screen Atari ST Emulator in monochrome (SM124) mode, like TOSBox!

That would be pretty cool!

Yea, and a back scratcher and a beer cooler and every episode of the walking dead and......

Yea, and a back scratcher and a beer cooler and every episode of the walking dead and......

Ok.

A beer cooler could be released via USB power supply. We got something similar here in Germany; keeps the coffee hot via USB power supply.

A back scratcher needs a Hardware and a Software team to release. Do we have a hardware team?

To include every episode of "the walking dead" could result in criminal prosecution. Better not!

To have a Atari ST Emulator (Full Screen, Monochrome) is easy to achive and will not end in criminal prosecution, because of the GPL3 License!

I have found Steem, Atari ST Emulator on the Web. It's published under the GPL3 License and could be easily included into an SFS file.

It seems to be very stable since I have recompiled all source code files from RSHs Score 5 in ST Pascal plus using Steem 3.2 ---> an it runs and works in LazY Puppy. Might work also in other puppies as well.

Not good enough for EVERY puppy. Needs to be 64bit multicolour!

I originally posted the following in the Slacko 5.4 thread back in Sept 2012 where it rather got buried. It seems more appropriate to post it here as it is still IMHO, as valid as ever.

--------------------------------------------------------------------------------------------------------
It is evident that this forum is littered with posts relating to boot issues with typically either:

1. The main SFS or save-file not being found or
2. The incorrect sfs or save-file being loaded.

These issues generally crop up when multiple pups are in use or more advanced boot techniques are being used where the component parts of puppy are being held on different drives, sub-directories and partitions.

I am aware that BK's philosophy, with which I totally agree, is that Puppy should in the main (with the possible exception of pmedia=) be capable of booting without other boot codes & be clever enough to work things out for itself.
In addition new users should not have to concern themselves with complex boot codes.

Currently the additional codes are intended by him to provide hints/help to Puppy when more complex arrangements are deployed.

This is fine for non-advanced use as probably 90% of users will have all the puppy files together in one directory.

The current problem with advanced use seems to be that the boot codes can sometimes conflict with or undermine the search logic that hunts down the location of firstly the save-file(s) and then the main sfs & any additional sfs files that the selected save-file calls for to be loaded. Often removing a boot code can help but more often than not one has to hit on the right combination of codes by a process of trial and error.

A couple of real world working examples:

CASE 1: Kernel on 16 MEG Smartmedia with main sfs & savefile on NTFS HDD (sda1)

CASE 2: Kernel on first Fat32 partition of USB2 flash main sfs & save file on 2nd ext4 partition of stick.

Both of the above were a nightmare to get right. It is of course a matter for BK, but what I propose is a new boot code (say SEARCH=NO) that would totally override the search logic and codes to allow for the precise location of the following to be specified:

A: The location of vmlinuz & initrd
B: The drive, partition & directory containing the main sfs and any additional sfs files.
C: The drive, partition & directory containing the save-file(s)

This would, I believe, eliminate the uncertainty and knock this thorny issue on the head once and for all.
If UUIDs could also be adopted so much the better.

ETP wrote:I originally posted the following in the Slacko 5.4 thread back in Sept 2012 where it rather got buried. It seems more appropriate to post it here as it is still IMHO, as valid as ever.

--------------------------------------------------------------------------------------------------------
It is evident that this forum is littered with posts relating to boot issues with typically either:

1. The main SFS or save-file not being found or
2. The incorrect sfs or save-file being loaded.



A couple of real world working examples:

CASE 1: Kernel on 16 MEG Smartmedia with main sfs & savefile on NTFS HDD (sda1)

Code: Select all

LABEL 5332 
MENU LABEL Slacko 5.3.3.2    05/07/12 
KERNEL /p5332/vmlinuz 
APPEND initrd=/p5332/initrd.gz pmedia=atahd pupsfs=sda1:/p5332/puppy_slacko_5.3.3.2.sfs pdev1=sda1

CASE 2: Kernel on first Fat32 partition of USB2 flash main sfs & save file on 2nd ext4 partition of stick.

Code: Select all

LABEL 5332 
MENU LABEL Slacko 5.3.3.2    05/07/12 
KERNEL /p5332/vmlinuz 
APPEND initrd=/p5332/initrd.gz pmedia=usbflash pupsfs=sdb2:/p5332/puppy_slacko_5.3.3.2.sfs psavemark=2

Both of the above were a nightmare to get right. It is of course a matter for BK, but what I propose is a new boot code (say SEARCH=NO) that would totally override the search logic and codes to allow for the precise location of the following to be specified:

A: The location of vmlinuz & initrd
B: The drive, partition & directory containing the main sfs and any additional sfs files.
C: The drive, partition & directory containing the save-file(s)

This would, I believe, eliminate the uncertainty and knock this thorny issue on the head once and for all.
If UUIDs could also be adopted so much the better.

Since it seems impossible to find out what the search "logic" is, I agree that your proposed kludge would be a desirable option. Since I only boot from either LiveCD or usbinstalls, using SFSs and 2fs files saved on the hard drive, my experience is limited, but fully as dismal as yours. If there is logic in the search the loader conducts, it has succeeded in eluding me.

I'm curious about the name and path of the file you excerpt in your two examples above, BTW.