You can add commands to the end of /etc/acpi/suspend.sh and they will run after it wakes up. Although, perhaps if you wait 1 minute the drive will shutdown again. You can check with 'hdparm -C /dev/sda'.sandungas wrote:
The problem now is when i close the lid (and the full machine enters in standby) this hdd settings get lost
Wich script is used when returning from standby ? it depends of the power adapter (/etc/acpi/superperformance.sh & /etc/acpi/powersave.sh) ?
Suggestions ?
Puppeee 4.3X
It seems that the full standby resets all settings, probably because is a standby managed by the bios ?
But is fixed by adding the hdparm command at the end of sleep.sh
Previously i was using 2 hdparm commands (-S to set the standby time... & -y to inmediatly standby)... because my first thought was to set standby to 5 minutes (or even more)
But as im using 1 minute countdown.. then i dont need the second one, i prefer not to send 2 consecutive hdparm commands
Can be good if this is included in puppeee, but only if there is a realiable way to identify mechanicall hdds to use something like this:
Im not a coder, is just a crappy way to explain the idea i thought to implement this 
---------------
Edit:
I saw in another forum that the hdd is able to store standby settings... by writing this settings in the hdd firmware (something that i prefer not to test)
I dont know if my hdd has no stored settings for standby (is not the originall 160gb hdd, i upgraded it to a 250gb one) i have windows xp & debian lenny installed and none of them uses standby in the hdd
I suspect about the eeepc bios, maybe this is the reason why the settings are lost when returning from standby
But is fixed by adding the hdparm command at the end of sleep.sh
Previously i was using 2 hdparm commands (-S to set the standby time... & -y to inmediatly standby)... because my first thought was to set standby to 5 minutes (or even more)
But as im using 1 minute countdown.. then i dont need the second one, i prefer not to send 2 consecutive hdparm commands
Can be good if this is included in puppeee, but only if there is a realiable way to identify mechanicall hdds to use something like this:
Code: Select all
if $sdX$ = $hdd_mechanicall$ then hdparm -S 12 /dev/$sdX$---------------
Edit:
I saw in another forum that the hdd is able to store standby settings... by writing this settings in the hdd firmware (something that i prefer not to test)
I dont know if my hdd has no stored settings for standby (is not the originall 160gb hdd, i upgraded it to a 250gb one) i have windows xp & debian lenny installed and none of them uses standby in the hdd
I suspect about the eeepc bios, maybe this is the reason why the settings are lost when returning from standby
-
aarf
just something else i have been able to do with battleshooters ffmpeg:aarf wrote:i have been using puppeee with battleshooters ffmpeg installed for a couple of hours and havent noticed any problems. if you have any places where you think breakage may occur i will test here if you list them.jemimah wrote:I was planning on updating to shinobar's ffmpeg build - it'll need testing. Anybody tried it - can you let me know if it's a problem free upgrade - or does anything break?
battleshooters ffmpeg isdont know what shinobars version isFFmpeg version SVN-r23652-snapshot, Copyright (c) 2000-2010 the FFmpeg developers
built on Jun 20 2010 19:12:42 with gcc 4.3.4
solve the playability of flash /tmp files very easily with
http://www.murga-linux.com/puppy/viewto ... 843#443843
maybe it doesn't need an upgrade to do this. i haven't tested the original ffmpeg
There is no way (yet) to tell the difference between SSDs and HDDs from the OS. Anyway, if you set the time out to longer than about 30 seconds a mounted drive will not shutdown since the kernel accesses the disk frequently. There is a kernel the feature called 'laptop mode' that is supposed to help with this. I may experiment with it in the future.sandungas wrote:It seems that the full standby resets all settings, probably because is a standby managed by the bios ?
But is fixed by adding the hdparm command at the end of sleep.sh
Previously i was using 2 hdparm commands (-S to set the standby time... & -y to inmediatly standby)... because my first thought was to set standby to 5 minutes (or even more)
But as im using 1 minute countdown.. then i dont need the second one, i prefer not to send 2 consecutive hdparm commands
Can be good if this is included in puppeee, but only if there is a realiable way to identify mechanicall hdds to use something like this:Im not a coder, is just a crappy way to explain the idea i thought to implement thisCode: Select all
if $sdX$ = $hdd_mechanicall$ then hdparm -S 12 /dev/$sdX$
---------------
Edit:
I saw in another forum that the hdd is able to store standby settings... by writing this settings in the hdd firmware (something that i prefer not to test)
I dont know if my hdd has no stored settings for standby (is not the originall 160gb hdd, i upgraded it to a 250gb one) i have windows xp & debian lenny installed and none of them uses standby in the hdd
I suspect about the eeepc bios, maybe this is the reason why the settings are lost when returning from standby
Puppeee 4.4X Beta 1 is coming soon. I've updated ffmpeg, xine, CUPS, GTK, glib, geany, and bluetooth-applet so far.aarf wrote:just something else i have been able to do with battleshooters ffmpeg:
solve the playability of flash /tmp files very easily with
http://www.murga-linux.com/puppy/viewto ... 843#443843
maybe it doesn't need an upgrade to do this. i haven't tested the original ffmpeg
-
aarf
sounds good. one other upgrade i recommend http://www.smokey01.com/coolpup/e2fspro ... .12-q1.pet to fsck the disk with the latest checker.jemimah wrote:
Puppeee 4.4X Beta 1 is coming soon. I've updated ffmpeg, xine, CUPS, GTK, glib, geany, and bluetooth-applet so far.
also thisscriptby neurino to automate the creation of playable flash from /tmp works to replace you2pup.
looking forward to a fully functional bluetooth-applet
-
aarf
did exactly this crash http://www.murga-linux.com/puppy/viewto ... 451#443451 in puppeee for the first time today.
different was that opera wasn't opened at all during the session.
was rendering a file in kdenlive which was larger that the remaining space in the pupsave that it was going into. i think time out for no key-pressing activity was also a factor. so i think that may be the combination that may cause the crash: no space left in pupsave and no key pressing activity causing the screen-saving-blank to cut in, then not having any memory to continue. just a guess though.
different was that opera wasn't opened at all during the session.
was rendering a file in kdenlive which was larger that the remaining space in the pupsave that it was going into. i think time out for no key-pressing activity was also a factor. so i think that may be the combination that may cause the crash: no space left in pupsave and no key pressing activity causing the screen-saving-blank to cut in, then not having any memory to continue. just a guess though.
jemimah,
While working with Toy4, we may have stumbled upon a subtle bug. He may be testing the idea soon so I can confirm it. The file /etc/ppp/peers/wvdial seems to result in an I/O error. I notice that that file and wvdial-pipe are in the puppeee system sfs file, but not in those of regular puppies.
Thanks.
Richard
A way to test the theory: in a console, enter the command:
cp -f /etc/ppp/wvdial /etc/ppp/peers/
If it produces a message, that would be the bug.
While working with Toy4, we may have stumbled upon a subtle bug. He may be testing the idea soon so I can confirm it. The file /etc/ppp/peers/wvdial seems to result in an I/O error. I notice that that file and wvdial-pipe are in the puppeee system sfs file, but not in those of regular puppies.
For the beta, could you remove those 2 files, leaving the /etc/ppp/peers directory empty? I will report further on the issue if it turns out to be real.Puppeee 4.4X Beta 1 is coming soon.
Thanks.
Richard
A way to test the theory: in a console, enter the command:
cp -f /etc/ppp/wvdial /etc/ppp/peers/
If it produces a message, that would be the bug.
here's what the README says about that:
That was giving me problems at one point so I moved it and probably disabled that behavior. But one of you updates may have reinstated that behavior.
wvdial and wvdial-pipe are supposed to be inside 'peers' directory,
however that conflicts with gkdial.
Therefore, /usr/sbin/gnomepppshell (gnome_ppp package, the GUI for wvdial)
moves these files into peers then back out afterward.
That was giving me problems at one point so I moved it and probably disabled that behavior. But one of you updates may have reinstated that behavior.
jemimah,
Logic says having the 2 files in /etc/ppp/peers should not cause a problem. My thinking is that maybe the layering file system does not handle the "cp -f" action, which removes the target file. It is a long shot, but removing those files would eliminate that as a possible cause.
Since I have no such I/O error on my 4.3.1 test system, I conclude that there is something different in puppeee 1.0 that might be behind the problem. I have connected from quirky (same kernel) with a USB analog modem, so the kernel must not be the factor. Is there anything else I should know about regarding modems and puppeee?
Richard
I don't see gnomepppshell in puppeee, at all. What did you move and where? Pupdial does that "behavior", so I am not sure how you would disable it./usr/sbin/gnomepppshell (gnome_ppp package, the GUI for wvdial) moves these files into peers then back out afterward.
That was giving me problems at one point so I moved it and probably disabled that behavior.
Logic says having the 2 files in /etc/ppp/peers should not cause a problem. My thinking is that maybe the layering file system does not handle the "cp -f" action, which removes the target file. It is a long shot, but removing those files would eliminate that as a possible cause.
Since I have no such I/O error on my 4.3.1 test system, I conclude that there is something different in puppeee 1.0 that might be behind the problem. I have connected from quirky (same kernel) with a USB analog modem, so the kernel must not be the factor. Is there anything else I should know about regarding modems and puppeee?
Richard
jemimah,
If pupdial was all you changed, that puts it back in my court. Do you recall what it was that made it necessary to change things? With Toy4, I see that the peers/wvdial files are probably missing at a point where they are expected. I have added some code for bluetooth that should not have executed, but that is the next suspect.
The presence of those files in the sfs does not appear to be the problem. They should get removed and replaced, which I have tested, but the problem persists. (This sounds like a dumb coding error on my part somewhere.) I'll keep after it.
Richard
If pupdial was all you changed, that puts it back in my court. Do you recall what it was that made it necessary to change things? With Toy4, I see that the peers/wvdial files are probably missing at a point where they are expected. I have added some code for bluetooth that should not have executed, but that is the next suspect.
The presence of those files in the sfs does not appear to be the problem. They should get removed and replaced, which I have tested, but the problem persists. (This sounds like a dumb coding error on my part somewhere.) I'll keep after it.
Richard
jemimah,
For the larger picture, I feel that having both of us modify pupdial and its friends is a setup for disaster. I cannot help users with their problems if they are using a version that I do not understand. I am grateful for your willingness to take the "bleeding edge" modem support, which helps me improve it. But I can waste a lot of users' and my time chasing problems not of my own making. I think everyone will benefit if we work together on modem fixes instead of "spinning our wheels".
Although my base for implementing modem improvements is still 4.3.1, my intent is that the modem (and module loading) improvements work for all later puppies, as well. So, I need to know about any issue you discover with these improvements.
On a separate subject, you mention in the fluppy thread about making fixes to 4.3.1 for fluppy. I am working on a "service pack" for the original 4.3.1 to add my improvements as well as some of the solutions posted in the 4.3.1 Bugs thread. Now that I have all I can use from that thread, I would like to add some of what you may have discovered. Here is a list of what I have so far, from my notes:
Richard
UPDATE: I looked at the puppeee 1.0 pupdial and like what you did with the "Connect" button. I have made that change to my version (7.4).
I have recently made a change for the same reason. Please check out the latest version (7.4) of pupdial. I moved the bottom row of buttons to above the log listing. Considering that we rarely need to consult the log after we get things going, this should make all of the controls available on the small screen.I change the UI so it fits on a smaller screen. I think this would be a good change for all Puppies since pupdial is really unusable on a small screen otherwise.
For the larger picture, I feel that having both of us modify pupdial and its friends is a setup for disaster. I cannot help users with their problems if they are using a version that I do not understand. I am grateful for your willingness to take the "bleeding edge" modem support, which helps me improve it. But I can waste a lot of users' and my time chasing problems not of my own making. I think everyone will benefit if we work together on modem fixes instead of "spinning our wheels".
Although my base for implementing modem improvements is still 4.3.1, my intent is that the modem (and module loading) improvements work for all later puppies, as well. So, I need to know about any issue you discover with these improvements.
On a separate subject, you mention in the fluppy thread about making fixes to 4.3.1 for fluppy. I am working on a "service pack" for the original 4.3.1 to add my improvements as well as some of the solutions posted in the 4.3.1 Bugs thread. Now that I have all I can use from that thread, I would like to add some of what you may have discovered. Here is a list of what I have so far, from my notes:
The purpose of the pack is to have something for new users of 4.3.1 to use to solve many of the old issues with it.Corrected reported bugs:
1. Typo in Pwireless (Bruce_n_Duane)
2. Shutdown hang on older PCs (noabody)
3. Clicking on a web link in documents viewed with Epdf - nothing happens (b...@openplatformeducation.org)
4. ALSA modems sometimes get detected as ttySL0, other times incorrectly as ttySHSF0 (rerwin)
5. Multiple monitor support (pizzasgood)
6. Module preferences not working properly to set priority of one module over another (rerwin)
7. Partview upgrade (ecube).
8. Monitor gamma correction button in Xorgwizard does nothing - replacement for "tkgamma" tool (PANZERKOPF)
9. Modules from initrd not gunzipped, impacting remastering (PANZERKOPF)
10. Make Puppy recover automatically from improper shutdowns (silverpuppy)
11. Roaring Penguin PPPOE fix to user instructions (fyujj)
12. How to cleanly unmount your filesystem on shutdowns, method 1 (Patriot)
13. Unload Ethernet drivers on shutdown to prevent laptop battery drain, but allow for WOL on mains-connected PCs (Shel)
Richard
UPDATE: I looked at the puppeee 1.0 pupdial and like what you did with the "Connect" button. I have made that change to my version (7.4).
My original modifications to pupdial were before I knew you were maintaining it. I am happy to leave it to you. 
I've made so many changes to 4.3.1 over the past year, it's hard to make a list. You should also look at Ttuuxxx's 4.3.2 thread if you haven't already. And Technosaurus has a bug tracker up on google code.
Let me think about it and I'll get back to you.
I've made so many changes to 4.3.1 over the past year, it's hard to make a list. You should also look at Ttuuxxx's 4.3.2 thread if you haven't already. And Technosaurus has a bug tracker up on google code.
Let me think about it and I'll get back to you.
-
aarf
puppeee1aarf wrote:did exactly this crash http://www.murga-linux.com/puppy/viewto ... 451#443451 in puppeee for the first time today.
different was that opera wasn't opened at all during the session.
was rendering a file in kdenlive which was larger that the remaining space in the pupsave that it was going into. i think time out for no key-pressing activity was also a factor. so i think that may be the combination that may cause the crash: no space left in pupsave and no key pressing activity causing the screen-saving-blank to cut in, then not having any memory to continue. just a guess though.
did this same crash again in opera10.61 with many open tabs and with /mnt/home at near completely full before starting opera, so overflow from the full pupsave would have nowhere to go. opera on a separate partition which still has space showing but also has 30% non contiguous when fsck is run.
Puppeee 1.0 and the 4G
Not sure which forum to post this in, here or the Puppeee.org/bb one. however the decision made itself, as I seem to be locked out of the ../bb forum at the moment.
Hi,
I have finaly got my old ASUS PC701 (eee 4G) going again. I've got Puppeee 1.0 booting from an ext2 USB stick and it is looking great. I'll probably transfer it to an SD card later.
Now I need to tune it up properly for the little beastie and I have some questions:
1/ I understand that the SSD in the 4G is the very first generation of these chips. Not only is it a bit slow but in Googling I found an authoritative-sounding article that stated that the load-leveling algorithm on these chips was seriously defective, so that in there is basically no load leveling at all in normal service. Since the SSD is soldered to the mother board, I would therefore prefer to use it as a read-only drive as far as possible, if I use it at all.
Is booting from the old 4G SSD likely to be significantly faster than from a modern USB flash stick or SD card? If it isn't, it is very easy, I will just not use the SSD, except to leave Xandros on it. However, if it is faster, I was thinking of placing initrd, vmlinuz, and all the sfs files on the SSD. Of course, I'd need to set up the SSD to multiboot. Is this a sensible approach and do you see any problems with it?
2/ I was also thinking of possibly using a very small pup-save, to hold only fairly fixed data, placing that on the SSD as well and putting all the regularly written files on replacable drives. In 432 I have a 32MByte pup-save that works well but some Puppies, such as Lupu, behave weirdly with small pup-saves. How small can I go?
3/ Does Puppy effectively set noatime for all flash drives? Is it a good idea? Are there any other tweaks to limit writing to flash that I should look at?
4/ I run ttuuxxx's 432 on my other PC. (great Puppy, pity it seems to be orphaned.) I am using Seamonkey 2 for browsing and IMAP email. Is it possible to get Chrome and Claws to import the Seamonkey profile? It's a pain to set up from scratch, especially for multiple IMAP accounts.
5/ I read somewhere that "Chrome" in Lupu is really Chromium, so it doesn't do the "phoning home" stuff that the real Chrome does. What is the situation in Puppeee?
Hi,
I have finaly got my old ASUS PC701 (eee 4G) going again. I've got Puppeee 1.0 booting from an ext2 USB stick and it is looking great. I'll probably transfer it to an SD card later.
Now I need to tune it up properly for the little beastie and I have some questions:
1/ I understand that the SSD in the 4G is the very first generation of these chips. Not only is it a bit slow but in Googling I found an authoritative-sounding article that stated that the load-leveling algorithm on these chips was seriously defective, so that in there is basically no load leveling at all in normal service. Since the SSD is soldered to the mother board, I would therefore prefer to use it as a read-only drive as far as possible, if I use it at all.
Is booting from the old 4G SSD likely to be significantly faster than from a modern USB flash stick or SD card? If it isn't, it is very easy, I will just not use the SSD, except to leave Xandros on it. However, if it is faster, I was thinking of placing initrd, vmlinuz, and all the sfs files on the SSD. Of course, I'd need to set up the SSD to multiboot. Is this a sensible approach and do you see any problems with it?
2/ I was also thinking of possibly using a very small pup-save, to hold only fairly fixed data, placing that on the SSD as well and putting all the regularly written files on replacable drives. In 432 I have a 32MByte pup-save that works well but some Puppies, such as Lupu, behave weirdly with small pup-saves. How small can I go?
3/ Does Puppy effectively set noatime for all flash drives? Is it a good idea? Are there any other tweaks to limit writing to flash that I should look at?
4/ I run ttuuxxx's 432 on my other PC. (great Puppy, pity it seems to be orphaned.) I am using Seamonkey 2 for browsing and IMAP email. Is it possible to get Chrome and Claws to import the Seamonkey profile? It's a pain to set up from scratch, especially for multiple IMAP accounts.
5/ I read somewhere that "Chrome" in Lupu is really Chromium, so it doesn't do the "phoning home" stuff that the real Chrome does. What is the situation in Puppeee?
Please let me know if you continue to experience problems at the other forum. I was under the impression that existing logins should continue to work.
If you put a frugal install on an SSD or flash drive, it should do the right thing automatically. Puppeee only writes to the drive during saving and shutdown, everything else happens completely in RAM.
The SiliconMotion SSD in the 4g is quite fast for booting, I definitely recommend using it (the Phison SSDs in later models are another matter). There is a post on Puppeee.com that tells you how to dual boot with Xandros.
I don't really know about exporting Seamonkey data. It should be possible to run Seamonkey on Puppeee - I've been meaning to make an SFS for that.
My impression is that most of the clamor about Chrome spying on you is hype by bloggers trying to get more traffic. It's justifiable to be worried about Google, but Chrome should probably be the least your worries.
I use Chrome because I like the way Google compiles it to work on a wider variety of distros (before I updated libc, I couldn't find a build of Chromuim that would even run). I've removed Chrome's auto update functionality and the other "features" can be turned off in the GUI. However, feel free to do your own research and draw your own conclusions.
If you put a frugal install on an SSD or flash drive, it should do the right thing automatically. Puppeee only writes to the drive during saving and shutdown, everything else happens completely in RAM.
The SiliconMotion SSD in the 4g is quite fast for booting, I definitely recommend using it (the Phison SSDs in later models are another matter). There is a post on Puppeee.com that tells you how to dual boot with Xandros.
I don't really know about exporting Seamonkey data. It should be possible to run Seamonkey on Puppeee - I've been meaning to make an SFS for that.
My impression is that most of the clamor about Chrome spying on you is hype by bloggers trying to get more traffic. It's justifiable to be worried about Google, but Chrome should probably be the least your worries.
I use Chrome because I like the way Google compiles it to work on a wider variety of distros (before I updated libc, I couldn't find a build of Chromuim that would even run). I've removed Chrome's auto update functionality and the other "features" can be turned off in the GUI. However, feel free to do your own research and draw your own conclusions.
Forum access and flash writes
Hi Jeminah,
Thanks for a quick reply. I am still locked out of the puppeee.org/bb forum. Logging in through the bb page says incorrect password and from the puppeee.com homepage says wrong password or arithmetic. So it seems to recognise my username (Snail, same as here). I tried to recover my password from the .org site and was told to expect an email, which didn't arrive.
Do you have a preferred policy on where queries like mine should go?
Both puppeee sites are extremely slow down here in New Zealand, this forum is much quicker, but still very slow.
After reading about the poor load balancing on my non-replacable SSD, I am really keen to avoid any writes to it. I like to keep my computers for a very long time and I use my eee quite heavily. My understanding was that unless noatime is set, linux writes to the drive whenever a file is accessed, even if it is only a read. So using any sfs file or the pup-save will trigger a disk write, even though they have not been written to in the session. Do I have that right? Also, is there any way to shut down without a save of the pup-save? This seems as if it could be useful in a number of situations.
I have set up a test 32MB pup-save. It seems to work OK, but the space warning blinker runs as only 15MB is free. Chrome seems to have slowed down. I have yet to move the Chrome equivalent of the Mozilla profile out of the pup-save filesystem however.
I installed to a USB flash using the standard zip file approach. I have an ext3 pupsave but the flash drive is formatted ext2, which i understand to be best for flash. The install went flawlessly. I was however a bit worried initially by the strong emphasis on using vfat in your instruction page. Admittedly there is a postscript that the installer can handle ext format, but the emphasis remains on using vfat. Why is this? Vfat is not even used for MS any more. I doubt very much if anyone will want to put their Puppeee sticks into a camera, which seems the main remaining use for vfat these days.
Thanks for a quick reply. I am still locked out of the puppeee.org/bb forum. Logging in through the bb page says incorrect password and from the puppeee.com homepage says wrong password or arithmetic. So it seems to recognise my username (Snail, same as here). I tried to recover my password from the .org site and was told to expect an email, which didn't arrive.
Do you have a preferred policy on where queries like mine should go?
Both puppeee sites are extremely slow down here in New Zealand, this forum is much quicker, but still very slow.
After reading about the poor load balancing on my non-replacable SSD, I am really keen to avoid any writes to it. I like to keep my computers for a very long time and I use my eee quite heavily. My understanding was that unless noatime is set, linux writes to the drive whenever a file is accessed, even if it is only a read. So using any sfs file or the pup-save will trigger a disk write, even though they have not been written to in the session. Do I have that right? Also, is there any way to shut down without a save of the pup-save? This seems as if it could be useful in a number of situations.
I have set up a test 32MB pup-save. It seems to work OK, but the space warning blinker runs as only 15MB is free. Chrome seems to have slowed down. I have yet to move the Chrome equivalent of the Mozilla profile out of the pup-save filesystem however.
I installed to a USB flash using the standard zip file approach. I have an ext3 pupsave but the flash drive is formatted ext2, which i understand to be best for flash. The install went flawlessly. I was however a bit worried initially by the strong emphasis on using vfat in your instruction page. Admittedly there is a postscript that the installer can handle ext format, but the emphasis remains on using vfat. Why is this? Vfat is not even used for MS any more. I doubt very much if anyone will want to put their Puppeee sticks into a camera, which seems the main remaining use for vfat these days.
I have no policy where queries go. However since this is only one thread, it's not easy to search. So it does other users a favor to ask FAQ-type stuff on the forum so I don't have to keep repeating myself.
Hopefully the server migration at Puppeee.com speeds things up. The database could not handle the load before, but at least for me it's better now.
Puppy mounts files relatime. I suppose I could modify the init script for noatime. I don't see any reason not to do so.
You probably want to look into RAMboot if you have at least a GB of RAM. Ramboot loads your save file into ram as well as all your sfs files and never touches the disk again. It is not setup to save at all, but since Patriots clean shutdown patched solved my problem the only reason it doesn't ask to save during shutdown is because I haven't implemented it.
You should format your save file with ext2 as well.
The install script was vfat-only until 2lss fixed it. I suppose I can update the website to be more clear about that. The new version of syslinux supports ext4 as well, but we're just waiting for me to have time to update the scripts.
Usb sticks come with vfat by default. I don't think windows offers to format them NTFS. Plus the installer won't support it, so vfat is your only option if you're installing from a windows machine.
Hopefully the server migration at Puppeee.com speeds things up. The database could not handle the load before, but at least for me it's better now.
Puppy mounts files relatime. I suppose I could modify the init script for noatime. I don't see any reason not to do so.
You probably want to look into RAMboot if you have at least a GB of RAM. Ramboot loads your save file into ram as well as all your sfs files and never touches the disk again. It is not setup to save at all, but since Patriots clean shutdown patched solved my problem the only reason it doesn't ask to save during shutdown is because I haven't implemented it.
You should format your save file with ext2 as well.
The install script was vfat-only until 2lss fixed it. I suppose I can update the website to be more clear about that. The new version of syslinux supports ext4 as well, but we're just waiting for me to have time to update the scripts.
Usb sticks come with vfat by default. I don't think windows offers to format them NTFS. Plus the installer won't support it, so vfat is your only option if you're installing from a windows machine.