Fatdog64-710 Final [4 Dec 2016]
- L18L
- Posts: 3479
- Joined: Sat 19 Jun 2010, 18:56
- Location: www.eussenheim.de/
solution for poulsbo graphics
Never got any new puppy or fatdog or quirky run on my computer before.
Archlinux gave me a solution.
No xorg driver modesetting needed
Only disadvantage: resolution cannot be changed without reboot.
Other operation systems which I could get running are slacko64 and remixOS (matter of kernel configuration).
Archlinux gave me a solution.
No xorg driver modesetting needed
Only disadvantage: resolution cannot be changed without reboot.
Other operation systems which I could get running are slacko64 and remixOS (matter of kernel configuration).
- Attachments
-
- poulsboro_grahic_successfully_used.png
- booted from grub4dos
- (123.37 KiB) Downloaded 1098 times
Re: solution for poulsbo graphics
Hi L18L, good t o se e you in the forum! Your post reminded me of the only computer I ever owned with poulsbo graphics. It was a Dell netbook. It worked very well with Windows XP but behind that, Windows 7 or Linux regardless, getting decent graphics output was a nightmare. I got rid of that computer. Glad you got yours tamed.
L18L wrote:Never got any new puppy or fatdog or quirky run on my computer before.
Archlinux gave me a solution.
No xorg driver modesetting needed
Only disadvantage: resolution cannot be changed without reboot.
Other operation systems which I could get running are slacko64 and remixOS (matter of kernel configuration).
[url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Fatdog64-810[/url]|[url=http://goo.gl/hqZtiB]+Packages[/url]|[url=http://goo.gl/6dbEzT]Kodi[/url]|[url=http://goo.gl/JQC4Vz]gtkmenuplus[/url]
@L18L: Greeting!
I'm glad to see you back, I hope everything is good for you.
@stemsee:
1. Open Control Panel
2. Find the "desktop" tab.
3. Launch "Fatdog Event Manager"
4. Change the "Grid width"
5. Click Save, then Quit.
6. Right-click any drive icon, then choose "Redraw all icons".
7. Repeat 3-6 until satisfied.
I'm glad to see you back, I hope everything is good for you.
@stemsee:
1. Open Control Panel
2. Find the "desktop" tab.
3. Launch "Fatdog Event Manager"
4. Change the "Grid width"
5. Click Save, then Quit.
6. Right-click any drive icon, then choose "Redraw all icons".
7. Repeat 3-6 until satisfied.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
@jamesbond: I thought I posted my reply, but apparently not.
I manually downloaded and checked the update, and installed it without issue. I'm sure you had already tested it, and knew it was correct! So, is it safe to uninstall and reinstall Gslapt? Are there any warnings or instructions for doing so?
Thank you.
I manually downloaded and checked the update, and installed it without issue. I'm sure you had already tested it, and knew it was correct! So, is it safe to uninstall and reinstall Gslapt? Are there any warnings or instructions for doing so?
Thank you.
Thanks Jamesbond.
I had trouble with screencaster; when changing directory for recordings to ~/Downloads, the recordings were being deleted. on examing the script I commented out one line and now its fine.
I am also having trouble getting host name change to persist!
I had trouble with screencaster; when changing directory for recordings to ~/Downloads, the recordings were being deleted. on examing the script I commented out one line and now its fine.
I am also having trouble getting host name change to persist!
- Attachments
-
- xscreenshot-20170219T153023.png
- (23.71 KiB) Downloaded 898 times
Hi stemsee, the real issue is that screencaster doesn't expand ~/Downloads into /root/Downloads as you expected. I think you can uncomment that line and enter the save path without ~, as in /root/Downloads. The output file name will end with .mp4 if you selected mp4 in the screencaster dialog. *.video and *.audio are partial files, and should be deleted.stemsee wrote: I had trouble with screencaster; when changing directory for recordings to ~/Downloads, the recordings were being deleted. on examing the script I commented out one line and now its fine.
Even if you had run screencaster from a terminal you wouldn't see any error messages, but this is a different issue that needs to be fixed in the script.
edit: fixed tilde expansion in my development copy of this script, now testing it...
[url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Fatdog64-810[/url]|[url=http://goo.gl/hqZtiB]+Packages[/url]|[url=http://goo.gl/6dbEzT]Kodi[/url]|[url=http://goo.gl/JQC4Vz]gtkmenuplus[/url]
- L18L
- Posts: 3479
- Joined: Sat 19 Jun 2010, 18:56
- Location: www.eussenheim.de/
Native Language Support
Thank you @step and @jamesbond for your welcome back messages.
momanager-2017.02.24-noarch-1.txz is successfully uploaded.
It is useable for English only devs now
you can use one TEXTDOMAIN for app and md doc
check the resulting pot file
avoid common mistakes like
e.g. having OK and Ok
@all
Nobody here who would like to add his language?
Just 2 TEXTDOMAINS:
fatdog for all the fatdog scripts
fatdoghelp for translation of fatdog's Help
Simply add fd64-nls_719.sfs to extrasfs parameter in boot code.
And install momanager-2017.02.24 using updated gslapt.
EDIT
Package attached as upload was not successful
EDIT
Attached package deleted as it was buggy
use package attached 2 posts downwards please
momanager-2017.02.24-noarch-1.txz is successfully uploaded.
It is useable for English only devs now
you can use one TEXTDOMAIN for app and md doc
check the resulting pot file
avoid common mistakes like
e.g. having OK and Ok
@all
Nobody here who would like to add his language?
Just 2 TEXTDOMAINS:
fatdog for all the fatdog scripts
fatdoghelp for translation of fatdog's Help
Simply add fd64-nls_719.sfs to extrasfs parameter in boot code.
And install momanager-2017.02.24 using updated gslapt.
EDIT
Package attached as upload was not successful
EDIT
Attached package deleted as it was buggy
use package attached 2 posts downwards please
- Attachments
-
- MoManager.png
- (151.51 KiB) Downloaded 699 times
Last edited by L18L on Sun 26 Feb 2017, 10:44, edited 2 times in total.
Re: Battery meter, battery usage, beautification
Original post: http://murga-linux.com/puppy/viewtopic. ... 714#938714
Your changes are good, but I can't include it as is into Fatdog64 because it seems the changes you've done is very specific to your laptop - for one thing, in my laptop I don't have any variable "charge_now" which you use for estimating power drain (it's "energy_now" in my laptop). I'll see if I can improve it.
@L18L, I hope you're doing well. I was a bit worried to not to see you in the forum for a while. I'm going to take your latest momanager and push it to the official repo, thanks!
And yes, so far there are only German translations (from you) ... still waiting to see others
cheers!
dr. Dan, thank you for this. Apology for the very long delay. I've finally managed to review this.Back in early Jan 20167, dr. Dan wrote:Hello all, I decided to try to improve the fatdog-battery-meter.sh script myself. It was a poor use of my time, but I know a little bit about the language now. Anyway, I added a rudimentary time left estimate which works on two different laptops so far.
Your changes are good, but I can't include it as is into Fatdog64 because it seems the changes you've done is very specific to your laptop - for one thing, in my laptop I don't have any variable "charge_now" which you use for estimating power drain (it's "energy_now" in my laptop). I'll see if I can improve it.
It's very difficult to asses, because 710 comes with newer kernel, newer graphics drivers, etc. Any of these could have impact on power usage. I would say that 710 is a bit bigger than 702 due to newer version of software, however it should not impact much. If you still can, run "htop" and to comparison between 702 and 710 when your system is idle. The difference should be minimal.Compared with 702, my battery life seems diminished. I don't know whether it is from using Seamonkey, but it seems to use a lot of memory.
You are very much welcome.Thanks for letting me play the home version of Fatdog64, it's a lot of fun. I keep finding additional features!
@L18L, I hope you're doing well. I was a bit worried to not to see you in the forum for a while. I'm going to take your latest momanager and push it to the official repo, thanks!
And yes, so far there are only German translations (from you) ... still waiting to see others
cheers!
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
- L18L
- Posts: 3479
- Joined: Sat 19 Jun 2010, 18:56
- Location: www.eussenheim.de/
Re: momanager in official repo
Thanksjamesbond wrote: I'm going to take your latest momanager and push it to the official repo, thanks!
bugs everywhere
Must work in working directory WD
Code: Select all
CACHE=$WD/cache ; mkdir -p $CACHE #130505
cd $WD #170224-2
Made and used in Fatdog64 (and latest slacko64)
Not intended to run in arm architectures.
- Attachments
-
- momanager-2017.2.24-noarch-2.txz.gz
- remove fake .gz
The only change is insert of line
cd $WD
after
CACHE=$WD/cache ; mkdir -p $CACHE #130505 - (33.69 KiB) Downloaded 188 times
Re: momanager in official repo
Thanks L18L!
Uploaded this to the official repo again, as build 2 too.
Uploaded this to the official repo again, as build 2 too.
To effect that comment, I added this snippet at the very top:L18L wrote:Made and used in Fatdog64 (and latest slacko64)
Not intended to run in arm architectures.
Code: Select all
## jamesbond - check arch
case $(uname -m) in
x86_64|i*86) ;; # good to go
*) Xdialog --title "MoManager" --infobox "Unsupported architecture: $(uname -m)" 0 0 10000
exit 1;;
esac
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Question about humongous initrd and base sfs file sizes
Question about humongous initrd and base sfs file sizes:
Been running Fatdog64 700 series on hard drive frugal installs for a while. And I always split out the fd64.sfs from the humongous initrd due to the booting being so painfully slow on all the machines I tried it on. But I noticed something different about the resulting file sizes with 710 Final compared to earlier versions like 702 and 700.
After following the same procedure for each, using the included fatdog-split-initrd.sh script, this is the results for 710:
- humongous initrd: 344M
- split fd64.sfs: 438M, plus small initrd: 3.5M = 441M
Compare that to 702: (with 702 script)
- humongous initrd: 250M
- split fd64.sfs: 255M, plus small initrd: 3M = 258M
And other older versions were similar, with the split files total only being a few MB larger than the humongous initrd. But with 710, the split out base sfs is huge for some reason, almost 100M more total. Is there something different about 710 that would cause this?
If using the copy out and repack method for 710, result is:
- fd64.sfs: 285M, plus large initrd: 59M = 344M (same as humongous)
Everything seems to be working OK though. But not sure if something in the script is over duplicating or possibly corrupting some files in the split process?
Just my observations.
Been running Fatdog64 700 series on hard drive frugal installs for a while. And I always split out the fd64.sfs from the humongous initrd due to the booting being so painfully slow on all the machines I tried it on. But I noticed something different about the resulting file sizes with 710 Final compared to earlier versions like 702 and 700.
After following the same procedure for each, using the included fatdog-split-initrd.sh script, this is the results for 710:
- humongous initrd: 344M
- split fd64.sfs: 438M, plus small initrd: 3.5M = 441M
Compare that to 702: (with 702 script)
- humongous initrd: 250M
- split fd64.sfs: 255M, plus small initrd: 3M = 258M
And other older versions were similar, with the split files total only being a few MB larger than the humongous initrd. But with 710, the split out base sfs is huge for some reason, almost 100M more total. Is there something different about 710 that would cause this?
If using the copy out and repack method for 710, result is:
- fd64.sfs: 285M, plus large initrd: 59M = 344M (same as humongous)
Everything seems to be working OK though. But not sure if something in the script is over duplicating or possibly corrupting some files in the split process?
Just my observations.
It's working as designed.
In 710 the default compression for splitted-out basesfs is "gzip". The resulting basesfs is bigger (about 150% - 200% larger) compard to xz compression used in older Fatdogs, but the actual splitting process is about 4x (that is, 400%) faster.
If small size is really what you're after, you can always run the splitter like this:Or for even smaller compression, use BASESFS_COMPRESSION="-comp xz -Xbcj x86". There are even ways to make it even smaller but it will affect run-time performance so it's not recommended.
In 710 the default compression for splitted-out basesfs is "gzip". The resulting basesfs is bigger (about 150% - 200% larger) compard to xz compression used in older Fatdogs, but the actual splitting process is about 4x (that is, 400%) faster.
If small size is really what you're after, you can always run the splitter like this:
Code: Select all
BASESFS_COMPRESSION="-comp xz" fatdog-split-initrd.sh ...
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
OK, that works, thanks.jamesbond wrote: If small size is really what you're after, you can always run the splitter like this:Code: Select all
BASESFS_COMPRESSION="-comp xz" fatdog-split-initrd.sh ...
Did split on main system, Core i7:
- humongous initrd: 344M
- split fd64.sfs: 353M, plus small initrd: 3.5M = 357M
That looks more normal like previous 70x base sfs sizes.
- split time (xz): 90 sec
- split time (gz): 20 sec
The split time, which is only done once is not the main issue, the slow boot time improvement is worth it.
Test system, boot to desktop, frugal HD install, AMD Vision E-350: (BIOS)
- huge initrd: 200 s
- small initrd: 50 s
Also tried on newer system, frugal USB install, ATOM Bay Trail Z3740: (32-bit EFI)
- huge initrd: 60 s
- small initrd: 30 s
That works for me.
@jamesbond: Thanks for looking, and I am only intending to be helpful to someone.
Just for curiosity, since I really do not know that much about system stuff, what files are in your laptop's path "/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/" (AKA the location of "$POWER_PATH/*/charge_now" on my systems? I had success on a Dell and a HP. I could try an Acer and an Asus, just to learn something.
I might be able to try running 702 and then 710 as a test, but it would be fairly inconvenient just now, so I'll ask for low expectations.
By the way, I installed FD710 on this HP using the Windows bootloader option, but it required a fair amount of research to learn how to configure the Windows 7 boot system to work. It was far from automatic!
Thanks as always.
Just for curiosity, since I really do not know that much about system stuff, what files are in your laptop's path "/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/" (AKA the location of "$POWER_PATH/*/charge_now" on my systems? I had success on a Dell and a HP. I could try an Acer and an Asus, just to learn something.
I might be able to try running 702 and then 710 as a test, but it would be fairly inconvenient just now, so I'll ask for low expectations.
By the way, I installed FD710 on this HP using the Windows bootloader option, but it required a fair amount of research to learn how to configure the Windows 7 boot system to work. It was far from automatic!
Thanks as always.
That's the spirit!dr. Dan wrote:@jamesbond: Thanks for looking, and I am only intending to be helpful to someone.
Well for the first thing, I don't have BAT0, I have BAT1. I don't have "charge_now", but I do have energy_now. My laptop is a Vaio.Just for curiosity, since I really do not know that much about system stuff, what files are in your laptop's path "/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/" (AKA the location of "$POWER_PATH/*/charge_now" on my systems? I had success on a Dell and a HP. I could try an Acer and an Asus, just to learn something.
I don't think it has anything to do with the versions. Just that different battery drivers (or ACPI) expose the same information in different way.I might be able to try running 702 and then 710 as a test, but it would be fairly inconvenient just now, so I'll ask for low expectations.
When you have installed it, the installer will create a file that you can run to automate the process; but it is highly recommended that you read the file before doing anything. There are several modes of Win7 installation, but I remember if you follow the common cases, you should be able to find that file in your C: drive when you boot to Windows. Did you see this file? What exactly did the problem you encounter?By the way, I installed FD710 on this HP using the Windows bootloader option, but it required a fair amount of research to learn how to configure the Windows 7 boot system to work. It was far from automatic!
Much welcome.Thanks as always.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
@ jamesbond
This was in regard to your suggestion that I compare idle state between the two for battery consumption.jamesbond wrote:dr. Dan wrote:I might be able to try running 702 and then 710 as a test, but it would be fairly inconvenient just now, so I'll ask for low expectations.
Thanks, it is working fine. I read the instructions repeatedly, ran the .exe file, but it did not accomplish the install successfully, so I modified the necessary files myself. I don't have enough understanding to help with diagnostics.When you have installed it, the installer will create a file that you can run to automate the process; but it is highly recommended that you read the file before doing anything. There are several modes of Win7 installation, but I remember if you follow the common cases, you should be able to find that file in your C: drive when you boot to Windows. Did you see this file? What exactly did the problem you encounter?By the way, I installed FD710 on this HP using the Windows bootloader option, but it required a fair amount of research to learn how to configure the Windows 7 boot system to work. It was far from automatic!
Much welcome.Thanks as always.
Oh, right. Well if the difference is not too big and you're not much affected then perhaps it's just the variation I said earlier.dr. Dan wrote:This was in regard to your suggestion that I compare idle state between the two for battery consumption.
No worries. Feel free to contact me if you have any problems with that in the future. In writing OS installer for dual-boot systems, "safety is number one priority" - I would rather the installation fail, rather that it messes the original OS the point that it won't boot. I tested the installer against pristine Win7, things may have changed with SP1 release and whatnot.Thanks, it is working fine. I read the instructions repeatedly, ran the .exe file, but it did not accomplish the install successfully, so I modified the necessary files myself. I don't have enough understanding to help with diagnostics.
cheers!
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
how to remove duplicate or any entry from fatdog-quick-locale-switcher?
- Attachments
-
- xscreenshot-20170304T193802.png
- (19.56 KiB) Downloaded 1141 times