spup-121.02 pre-alpha3 based on 13.37

[wuwei]

Sorry Billtoo,

this SFS doesn't work on this setup:

Lucid525 LiveCD plus USB-Flashdrive for the existing pupsavefile.

Downloaded the SFS, moved it to /mnt/home on the flash drive, tied it in with SFS-on-the-fly .... it didn't start.
Rebooted and tried again, from the menu, from the .desktop symbol in /usr/share/applications, by moving a videofile on the starter symbol...nothing moves.

Next will be a test with pfix=ram and a brand new lupusave file.
That is no better.

But hey, this is the spup thread, so I'll try it there.

Okay, now on a frugal install to HDD of spup121.02:
Pull in the SFS by means of SFS-on-the-fly.
Menu entry established; call the application through the menu
Error screen shows up, see picture.
But the player works,
both when opening a video file through the menu item File and when dragging a video file on the VLC gui.

So, looks pretty good, except for the error window. But that could be my setup.


(Sorry for my initial stupidity )

[wuwei]

Now I have experimented a little further.

Dragged the starter from /usr/share/applications to the desktop and assigned an icon.

When I start VLC now from the desktop, there is no error message anymore. Same when pulling a video file to the desktop icon.

Works perfectly in contrast to my mind this early in the morning

[mikeslr]

Hi All,
Deleted old SaveFile and rebooted. OTTB, display was 1600x900 using Ati Radeon. Per 01micko's instructions,
http://www.murga-linux.com/puppy/viewto ... 768#528768
deleted /etc/X11/xorg.conf and /etc/xorg-auto, installed xorgconfigauto-1.pet and rebooted. Boot stopped short of desktop, but typing xwin brought me to it with above, proper, display. Changed time-zone without incident. Established internet via Simple Network Setup and accessed Youtube which played with sound, albeit had to add appropriate sliders and increase volume to satisfy these old ears.
Rebooted. Again boot stopped before desktop which was reached by typing xwin. Proper display had survived. Wifi setting, however, had not been saved.

My system:
Processor: 4x AMD Phenom(tm) II X4 945 Processor
Memory: 3375MB
Resolution: 1600x900 pixels
VGA compatible controller: ATI Radeon 3100 Graphics
Network controller: RaLink RT2561/RT61 802.11g PCI


Is there someway now to get to desktop without having to type "xwin"?
Edit: Solved. Finally remembered to delete "nox" argument from Menu.lst.

I'll review thread regarding non-persistence of Wifi settings, but suggestions are welcome.
Edit: On Reboot, last Wifi settings had been retained.

Before trying the xorgconfigauto-1.pet I meandered over to the Squeeze thread to review developments there. That reminded me that others and myself were having display problems that Stu90 had examined:
http://www.murga-linux.com/puppy/viewto ... 233#525233 and posted,
"Hi tuuxxx,
regarding the xorgwizard:
In woof i swapped squeezed xorg_base package for lucid525 xorg_base package and i am now able to get to the desktop with xorgwizard / probe with out getting dropped back to prompt or having to select a driver.

Here is both xorg_base packages in case you want to compare.
http://www.mediafire.com/file/gbr7pdt0p ... ase.tar.gz

In American Jurisprudence, one of the reasons for disqualifying a potential juror is that he or she has any relevant knowledge about what's going on. On that basis, I'm qualified to guess that there may be a problem with the most recent Woof. Someone who knows what he or she is doing may find it useful to also compare Slacko's xorg base package with those Stu90 has provided.

mikesLr

[mikeslr]

Hi All again,

Booted into Slacko. Just realized that I got onto desktop without having to type "xwin." Decided to work on a Wallpaper, so I used SFS-on-the-fly (or whatever it's called, as I'm currently in Lupu) to load Gimp_2.6.11.sfs. As I'm not that familiar with "SFS-on-the-fly" I'm not certain whether the SFS failed to load the first time, or I did something wrong, but the second time it loaded. In Gimp I resized a Wallpaper to 1600x1200 intending to cut it down to 1600x900, (my screen size) via copy & paste, and then make changes. My computer hung when 2nd large file was created. Note I have 3+ Gigs of memory, 6 Gig Swap partition and a 512 SaveFile.

As I had to do a hard shut down, literally pull the plug, being uncertain what effect that will have, I'm reporting from Lupu525. I'll report the effect once I'm back in Slacko.

Edit: Booted back into Slacko. Booting stopped before desktop. Typed "xwin" and received the "Ignore" or "Commandline" option. Chose the latter, typed "Xorgwizard" "Chose" Ati Radeon @ 1600x900x24, got a black screen and moments later a "No Signal." Rebooted, same as above except this time selected "ignore" --What did I have to loose?-- and reached desktop per previous settings of 1600x900x24. But my wireless settings were no longer in effect and had to re-run Simple Network Setup.

Maybe, at the beginning of this post, I misrecollected not having to type "xwin"?
Edit: I must have misrecollected, as I later discovered that the "nox" argument still existed in Menu.lst.

mikesLr

p.s. I could not add mtpaintsnapshot to JWM's tray. I don't think this is a Slacko problem, as I've also been unable to add it to some other recent puplets (a woof problem?) while I could, and did, add PupSnap to the tray.

[playdayz]

Qt Interest Group.

Just an idea. People interested in Qt programs----that is VLC, Musescore, Amarok/Clementine, and others--might want to consider ahead of time and coordinate a policy for using Qt. I mention this because there are several versions of Qt in play now--the VLC 1.1.5 for Lucid uses 4.5.3, Musescore uses 4.7.3, Clementine uses 4.7.2, and so forth. In at least one case there is an incompatibility--Musescore and Clementine conflict and both will not run at the same time (discovered by jim1911). This is no huge deal--since the programs are all add-ons and it is too late to fix it much in lucid but a policy might prevent it happening in Spup.

----------------------------------------------------------------

Another darn idea.

I just answered a message from a person who was worried about "investing in the wrong Puppy" meaning, in the past 4.3.1 was clearly the one official Puppy--now it is different. Plus, there are worries when updating the something could go wrong and crater one's data.

This is a big project--not simple--but maybe worth discussing: a separate save file for data. Currently the modifications one makes to Puppy, by adding pets, etc., and one's data are kept in the same save file--and it is the one that is updated with a new Puppy. But if there was separate save file for data then one could boot any Puppy and work on that same data, and upgrading any Puppy would not touch the save file with one's data in it. One can do something similar now by keeping data in /mnt/home--but I am thinking less experienced users might not understand that and it might be better to do it automatically. Barry would have to do this in the scripts--I am not even sure about the details.

[cowboy]

Another darn idea.

I just answered a message from a person who was worried about "investing in the wrong Puppy" meaning, in the past 4.3.1 was clearly the one official Puppy--now it is different. Plus, there are worries when updating the something could go wrong and crater one's data

a separate sfs file for data...if there was separate sfs for data then one could boot any Puppy and work on that same data, and upgrading any Puppy would not touch the sfs file with one's data in it. One can do something similar now by keeping data in /mnt/home--but I am thinking less experienced users might not understand that

sounds like two great ideas.

[emil]

I think pets go into the personal savefile together with the personal data, and the savefile is not an sfs but a file formatted to ext2 or ext3 (uncompressed). Having seperated programm and data savefiles (maybe also separate settings savefile - e.g. screensavers) would add additional layers to the filesystem.

The max amount of layers was very restricted with standard puppy due to performance considerations. An additional "savefile layer" could mean skipping one possible "sfs file layer".
However experience with recent developement weakend this barrier (various different sfs loaders. I didn't test those myself, I just try to recall what I read on the forum). Performance seems to be acceptable even with increasing numbers of layers in the filesystem.

Advantage of shared user-data savefile:

• less diskspace needed if running different puppies.
  Changes in the data are visible from all other puppies.
  Data is very portable because encapsuled in one file.

Disadvantage:

• Maybe small performance loss in filesystem.
  Complicate the very simple puppy setup.

A simpler suggestion would be to write a small gui script which allows to mount 2fs/3fs (aka savefiles) and copy the contents of its /root/mydocuments directory over to the running puppy. Not an obvious option for new puppy users.

please correct or ignore me if I am plain wrong or off-topic...
kind regards
emil

[playdayz]

I think pets go into the personal savefile together with the personal data, and the savefile is not an sfs but a file formatted to ext2 or ext3 (uncompressed).

Yes emil, Thank you. I was thinking too fast. I corrected it by changing 'sfs' file to 'save' file.

it occurs to me that traditional Linux achieved something of the same with the Home directory--that would often be placed on a separate partition so the main Linux could be updated without touching the Home directory(s).

[DaveS]

I think pets go into the personal savefile together with the personal data, and the savefile is not an sfs but a file formatted to ext2 or ext3 (uncompressed).

Yes emil, Thank you. I was thinking too fast. I corrected it by changing 'sfs' file to 'save' file.

it occurs to me that traditional Linux achieved something of the same with the Home directory--that would often be placed on a separate partition so the main Linux could be updated without touching the Home directory(s).

Can Puppy be made to install such that it creates a normal folder, say, my-documents, at mnt/home, symlinked back to /root/. The advantages of this are dynamic size, and uncompressed data if the system fails, making retrieval easier. This is how I do it anyway, just have to set it up by hand. Such a folder is of course easily shared.

[cowboy]

I think pets go into the personal savefile together with the personal data, and the savefile is not an sfs but a file formatted to ext2 or ext3 (uncompressed).

it occurs to me that traditional Linux achieved something of the same with the Home directory--that would often be placed on a separate partition so the main Linux could be updated without touching the Home directory(s).

Can Puppy be made to install such that it creates a normal folder, say, my-documents, at mnt/home, symlinked back to /root/. The advantages of this are dynamic size, and uncompressed data if the system fails, making retrieval easier. This is how I do it anyway, just have to set it up by hand. Such a folder is of course easily shared.

again, both DaveS and Playdayz are on to something here. And I still think it's great - but with one minor quibble. One of the cool things about Puppy is the savefile. Back it up, and you are backed up. For a newbie, perhaps installing Puppy on a Windows machine for the first time, having that separate save file is a comfort. And we've all seen many posts on the beginners forum along the lines of "how many home folders am I supposed to be seeing...etc?".

There is no doubt that having data outside the savefile has many benefits, and it might be an excellent option to provide. As a default? dunno. Personally, it was part of my Linux learning curve - savefile; savefile getting too full; oh, I can put things outside the savefile (thanks DaveS and mikeslr). In a world of video files and giant .raw photo files, you'll have to make that transition at some point.

[Béèm]

Another darn idea.

I just answered a message from a person who was worried about "investing in the wrong Puppy" meaning, in the past 4.3.1 was clearly the one official Puppy--now it is different. Plus, there are worries when updating the something could go wrong and crater one's data.

This is a big project--not simple--but maybe worth discussing: a separate save file for data. Currently the modifications one makes to Puppy, by adding pets, etc., and one's data are kept in the same save file--and it is the one that is updated with a new Puppy. But if there was separate save file for data then one could boot any Puppy and work on that same data, and upgrading any Puppy would not touch the save file with one's data in it. One can do something similar now by keeping data in /mnt/home--but I am thinking less experienced users might not understand that and it might be better to do it automatically. Barry would have to do this in the scripts--I am not even sure about the details.

A save file will always have limitations.
Is that better?
I don't think users are to be underestimated.
Saving ones documents, spreadsheets, music, audio, etc.. isn't a difficult concept. Whether it is in Windows or in Linux.

[Jim1911]

Qt Interest Group.

Just an idea. People interested in Qt programs----that is VLC, Musescore, Amarok/Clementine, and others--might want to consider ahead of time and coordinate a policy for using Qt. I mention this because there are several versions of Qt in play now--the VLC 1.1.5 for Lucid uses 4.5.3, Musescore uses 4.7.3, Clementine uses 4.7.2, and so forth. In at least one case there is an incompatibility--Musescore and Clementine conflict and both will not run at the same time (discovered by jim1911). This is no huge deal--since the programs are all add-ons and it is too late to fix it much in lucid but a policy might prevent it happening in Spup.

----------------------------------------------------------------

Another darn idea.

I just answered a message from a person who was worried about "investing in the wrong Puppy" meaning, in the past 4.3.1 was clearly the one official Puppy--now it is different. Plus, there are worries when updating the something could go wrong and crater one's data.

This is a big project--not simple--but maybe worth discussing: a separate save file for data. Currently the modifications one makes to Puppy, by adding pets, etc., and one's data are kept in the same save file--and it is the one that is updated with a new Puppy. But if there was separate save file for data then one could boot any Puppy and work on that same data, and upgrading any Puppy would not touch the save file with one's data in it. One can do something similar now by keeping data in /mnt/home--but I am thinking less experienced users might not understand that and it might be better to do it automatically. Barry would have to do this in the scripts--I am not even sure about the details.

Super ideas.

1. I vote for QT 4.7.3.

2. As for a separate save file for data, this is definitely worth considering. Using mnt/home with relative links for key items such as My Documents back to /root works well and could be implemented automatically for inexperienced users, however, the root files selected for a separate save file need to be very selective and have options for user choices. In my installations, items such as .mozilla, .thunderbird, and .wine are always in /mnt/home/ with relative links back to /root and these are used by many different pups. Of course, it is important to maintain backups of these key files. This would be easy if there is a separate save file.

[playdayz]

Seamonkey 2.1

This is the release of Seamonkey 2.1. I compared it to Seamonkey 2.0.14 from Spup. I don't mean to disrespect Seamonkey 2.0.14, but this is a significant speed improvement. SM 2.1 is larger though, 20MB pet. I didn't try at all to shrink it--in fact, as I understand it, optimizing at the highest level would make the code larger, somewhat. After installing the pet, the Browser icon opens SM 2.0.14 and the Seamonkey menu entry opens SM 2.1. In the graphic from Peacekeeper, higher is better. Firefox 4.0.1 gets about the same score as SM 2.1 on my machine.

(In the previous version of this post, the Seamonkey 2.1 was not actually any faster than the generic download from mozilla.org. I do not know why. But this one is. The 4009 score is for Seamonkey 2.1 compiled with -march=amdfam10--that is, for AMD Phenoms. The 3751 score is for the i686 version of Seamonkey 2.1--which is the one available now. The generic version scores in the low 3600's. The generic version of Firefox 4.0.1 also scores in the low 3600's.)



Seamonkey 2.1 -> http://diddywahdiddy.net/Puppy500/Seamo ... 1-i686.pet

[Lobster]

a separate save file for data.

Puppy usuage and expectation has changed.
Users may well be confused when their data expands
and their personal storage file does not automatically expand to take up space on their 'plenty of space left' hard disk.

My solution is to run Puppy from DVD and keep data
on a seperate hard disk
In other words keeping operating system and data seperate.

There was some talk/experimentation of a dynamicaly expanding save file
- was it from Barry or Iguleder, or did I dream it?

As part of the effort to make Spup and eventually Spot more secure
we can create a wiki page on 'Keeping your data secure' moving towards a tutorial/link/solution?

[DaveS]

Cowboy.... did you follow up on this: http://www.murga-linux.com/puppy/viewto ... 276#532276

[Iguleder]

01micko - a very neat trick I found yesterday.

Usually, I compile my kernels under the Puppy I run, so the GCC version isn't stable as Debian's. That's what Puppy devs do, traditionally.

However, yesterday I tried a trick - I created a Debian Wheezy chroot environment with GCC 4.5.x (because 4.6.0 has many critical regressions) and compiled 2.6.32.41 (an upgrade from .40 ).

Guess what? 2 MB difference in package size and it's supposed to be much faster due to all the nifty optimizations of GCC >4.4.

There's only one problem with this approach: you'll need to keep the chroot environment/distro/whatever you used to build the kernel and build all third party and extra drivers with it, so you don't screw it up.

[Bert]

and what if the whole /root would be a symlink to /mnt/home/root?

Apologies if this is a stupid idea

EDIT Oops, I replied to cowboy, before seeing there were more posts after his...

[mikeslr]

Hi All,
I'm not sure how much space it would save, but Simple-Scan is a much more user-friendly, intuitive interface to Sane than Xsane. After tubby figured out what files were actually needed in Lupu, http://murga-linux.com/puppy/viewtopic. ... 209#446209, I packaged them together in a pet which only used 132.55 KB. http://murga-linux.com/puppy/viewtopic. ... 824#532824. Of course, the XSane front end could still be available via PPM for those who need it.

A Slackware version of Simple-Scan has a compressed size of 167,00 KB, http://pkgs.org/slackware-13.37/slacker ... f.txz.html but that probably includes "docs."

Sorry I can't test it in Slacko. Only my wife's computer has a scanner attached, and having been a only child, she finds it difficult to share.

mikeslr

[Minnesota]

Pardon my ignorance of how the file system and PupSave actually works.. by why is there any restriction on the size? Most file systems allow for expanding number of records in a file. Why is the file a fixed length? What is unique about the way our save file is structured that it can not automatically expand?

Most devices that we save to.. Hard disk, stick, CD, DVD, all can handle expanding file sizes. Certainly it is necessary to determine maximum space for a save, that is, is there enough space to make the save. That should be easy to determine.

[cowboy]

Cowboy.... did you follow up on this: http://www.murga-linux.com/puppy/viewto ... 276#532276

DaveS - followed up just now: http://www.murga-linux.com/puppy/viewto ... 276#532276

Thank you. A full report is on the other thread, but linking merely the contents of the .mozilla folder in root to the profile in mnt/home worked!