See ISObooter Page 12.greengeek wrote:4) Consider finding ways to eliminate the savefile altogether. You can change the savefile to an sfs (readonly) and this avoids shutdown write delays completely.
Flash drive Puppy settings didn't take
@bigpup
that reference you provided: https://www.thegeekstuff.com/2010/09/li ... structure/ is one of the best examples of what Puppy users, coming from Windows or any other system, need to understand to be able to confidently use the file system.
I bet many Puppy users, even of long standing, use /usr /bin and all the rest not knowing exactly what those files are intended to be doing, but since they've managed to get their Puppy working for them don't enquire too much further. Bad thinking IMO. Once the light has clicked on in your head about the general structure it clears up so many questions - and in truth the explanation is not rocket science just a simple de-mystification.
I reckon I could make a lot of money taking bets on how many Puppy users think 'usr' means 'user' (and sometimes it does)... You can see by the many comments following that reference how much of that type of explanatory stuff is needed. Ironically, it is often there somewhere but so much Puppy information isn't easily searchable - typing in a search topic once got me 500+ pages of references but looking for my needle in that haystack just wasn't feasible. I understand why things have developed that way just a shame the truly fundamental stuff isn't in one place?
When the day comes that I have a good understanding of Puppy I'm gonna do a long write up on what I think newcomers need as a starting point with no asumptions about anything. A handful of step-by-step guides on why things are the way they are and a few elementary "How-to's" would do the trick. There are already a few how-to's which start off the right way for beginners but then suddenly say stuff like "you need to compile xyz.." then set "pfdisk=HTse" (just made up) and that drops the beginner in the brown stuff right off the bat. Hard isn't it?
This is not a whinge about Puppy or its posters - both are excellent - but it remains difficult for newcomers to Linux systems get their head around the basics with no basic roadmap.
that reference you provided: https://www.thegeekstuff.com/2010/09/li ... structure/ is one of the best examples of what Puppy users, coming from Windows or any other system, need to understand to be able to confidently use the file system.
I bet many Puppy users, even of long standing, use /usr /bin and all the rest not knowing exactly what those files are intended to be doing, but since they've managed to get their Puppy working for them don't enquire too much further. Bad thinking IMO. Once the light has clicked on in your head about the general structure it clears up so many questions - and in truth the explanation is not rocket science just a simple de-mystification.
I reckon I could make a lot of money taking bets on how many Puppy users think 'usr' means 'user' (and sometimes it does)... You can see by the many comments following that reference how much of that type of explanatory stuff is needed. Ironically, it is often there somewhere but so much Puppy information isn't easily searchable - typing in a search topic once got me 500+ pages of references but looking for my needle in that haystack just wasn't feasible. I understand why things have developed that way just a shame the truly fundamental stuff isn't in one place?
When the day comes that I have a good understanding of Puppy I'm gonna do a long write up on what I think newcomers need as a starting point with no asumptions about anything. A handful of step-by-step guides on why things are the way they are and a few elementary "How-to's" would do the trick. There are already a few how-to's which start off the right way for beginners but then suddenly say stuff like "you need to compile xyz.." then set "pfdisk=HTse" (just made up) and that drops the beginner in the brown stuff right off the bat. Hard isn't it?
This is not a whinge about Puppy or its posters - both are excellent - but it remains difficult for newcomers to Linux systems get their head around the basics with no basic roadmap.
If you could do that, based on a new users view of Puppy, that would be great.
There are usually 6 or more ways to do about anything in Puppy.
Giving a new user the simple, easy way, needs some input from a very new user.
Great way to give back to Puppy.
This was the original FAQ page for Puppy, controlled by the original Puppy developer, Barry K.
http://bkhome.org/archive/puppylinux/faq.htm
When he stopped controlling Puppy development and turned it all over to the Puppy community.
It got archived because he shutdown his active Puppy web pages.
Still some useful info in it, even if it is a little old and not updated to the newest Puppies.
There are usually 6 or more ways to do about anything in Puppy.
Giving a new user the simple, easy way, needs some input from a very new user.
Great way to give back to Puppy.
This was the original FAQ page for Puppy, controlled by the original Puppy developer, Barry K.
http://bkhome.org/archive/puppylinux/faq.htm
When he stopped controlling Puppy development and turned it all over to the Puppy community.
It got archived because he shutdown his active Puppy web pages.
Still some useful info in it, even if it is a little old and not updated to the newest Puppies.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
rcrsn51 has highlighted an excellent way of getting usb "savefile" writes to terminate quickly (and therefore successfully) at shutdown time.:rcrsn51 wrote:See ISObooter Page 12.
see http://murga-linux.com/puppy/viewtopic. ... 264#864264
Anything that reduces usb write time during shutdown has the potential to reduce potential triggers for savefile corruption.
I have a general question: can a usb stick run out of free space for containing a savefile, or is that space already allocated and available even if the stick fills up with other stuff? Could a savefile save process be negatively affected by a stick being full and fragmented?
Hi GreenGeek !
Good Question ....#Me-curiousToo......I have a general question: can a usb stick run out of free space for containing a savefile, or is that space already allocated and available even if the stick fills up with other stuff? Could a savefile save process be negatively affected by a stick being full and fragmented?
- Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
Morning, GG.
I'm no expert on this one, but AFAIK if a save file has been created, then it shouldn't be affected by 'other stuff'.
Say (for the purposes of illustration) that you've got a 2 GB savefile on an 8 GB stick. No matter what happens, Puppy only has 6 GB for itself and 'other stuff'. That 2 GB is ear-marked; I don't pretend to understand how Puppy creates save-files, but it's as though that 2 GB is already full, even though, to start with, it's empty.
I'm guessing that the inodes, or whatever metadata 'pointers' are in use, are telling the file-system that the new, 'empty' save-file is already occupying that 2 GB of space. It is, in effect, a 2 GB-sized 'container'.
Does any of that even make sense? I know what I'm trying to say, but I'm not always so good at putting it into words; the grey matter's not so nimble as it once was..!
----------------------------------------
As to how fragmentation would affect it, I don't know. I have no idea whether the 2 GB of space our hypothetical save-file occupies can fragment, once created. We need a real expert for that one; I guess the only person who could give a definitive answer, one way or another, would be BK himself.
The only thing I can say for definite is that which we all know.....and that is that fragmentation is very much less with a Linux file-system that it is with a Windoze one, due to the ways in which the two write data to storage devices.
NTFS writes each and every sequential data 'packet' to the first available bit of space it finds, whereas any Linux file-system, whether ext 2/3/4/whatever, will make a concerted effort to keep as much of any given data file together, as close as it can. AFAICT, it's perfectly possible for the space within the save-file to fragment, just as it can outside of it.....I simply don't know enough about it to say otherwise.
Mike.
I'm no expert on this one, but AFAIK if a save file has been created, then it shouldn't be affected by 'other stuff'.
Say (for the purposes of illustration) that you've got a 2 GB savefile on an 8 GB stick. No matter what happens, Puppy only has 6 GB for itself and 'other stuff'. That 2 GB is ear-marked; I don't pretend to understand how Puppy creates save-files, but it's as though that 2 GB is already full, even though, to start with, it's empty.
I'm guessing that the inodes, or whatever metadata 'pointers' are in use, are telling the file-system that the new, 'empty' save-file is already occupying that 2 GB of space. It is, in effect, a 2 GB-sized 'container'.
Does any of that even make sense? I know what I'm trying to say, but I'm not always so good at putting it into words; the grey matter's not so nimble as it once was..!
----------------------------------------
As to how fragmentation would affect it, I don't know. I have no idea whether the 2 GB of space our hypothetical save-file occupies can fragment, once created. We need a real expert for that one; I guess the only person who could give a definitive answer, one way or another, would be BK himself.
The only thing I can say for definite is that which we all know.....and that is that fragmentation is very much less with a Linux file-system that it is with a Windoze one, due to the ways in which the two write data to storage devices.
NTFS writes each and every sequential data 'packet' to the first available bit of space it finds, whereas any Linux file-system, whether ext 2/3/4/whatever, will make a concerted effort to keep as much of any given data file together, as close as it can. AFAICT, it's perfectly possible for the space within the save-file to fragment, just as it can outside of it.....I simply don't know enough about it to say otherwise.
Mike.