Fatdog64-710 Final [4 Dec 2016]

[step]

@jamesbond, I misconfigured wpa_supplicant on purpose, just to show an example I could capture for my post.

[jamesbond]

@step - yes, of course.

@stemsee: Thank you stemsee.

To run wpa_supplicant so it can support multiple wifi interface, do it like this:
wpa_supplicant -i wlan0 -c/etc/wpa_supplicant.conf -N -i wlan1 -c/etc/wpa_supplicant1.conf -N -i wlan2 -c/etc/wpa_supplicant2.conf ... ad nauseam.

wpa_supplicant.conf, wpa_supplicant1.conf, wpa_supplicant2.conf etc can be the same file if you wish (which is what I did for my example).

Fatdog uses wpa_supplicant (for obvious reasons), wpa_cli (for automatic IP address setting) and wpa_gui. To support multiple interfaces, wpa_gui does not need to change; wpa_supplicant needs to be modified as above; and wpa_cli needs to be run multiple times, one for every interface.

EDIT: the "pt" workaround is to run setxkbmap -query as soon after running setxkbmap.

[L18L]

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).

[drunkjedi]

Thanks James for the Gif screencapture help.

[step]

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.

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).

[stemsee]

Fatdog desktop drive icons .... How do I increase the spacing between the desktop drive icons?

[jamesbond]

@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.

[dr. Dan]

@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.

[stemsee]

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!

[step]

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.

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.

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...

[L18L]

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

[jamesbond]

Original post: http://murga-linux.com/puppy/viewtopic. ... 714#938714

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.

dr. Dan, thank you for this. Apology for the very long delay. I've finally managed to review this.

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.

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.

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.

Thanks for letting me play the home version of Fatdog64, it's a lot of fun. I keep finding additional features!

You are very much welcome.

@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!

[L18L]

I'm going to take your latest momanager and push it to the official repo, thanks!

Thanks

bugs everywhere
Must work in working directory WD

Code: Select all

CACHE=$WD/cache ;  mkdir -p $CACHE #130505
cd $WD #170224-2

Made it (cd $WD) as build number 2 (thanks Fatdog's Help files)

Made and used in Fatdog64 (and latest slacko64)
Not intended to run in arm architectures.

[jamesbond]

Thanks L18L!
Uploaded this to the official repo again, as build 2 too.

Made and used in Fatdog64 (and latest slacko64)
Not intended to run in arm architectures.

To effect that comment, I added this snippet at the very top:

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

[jd7654]

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.

[jamesbond]

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:

Code: Select all

BASESFS_COMPRESSION="-comp xz" fatdog-split-initrd.sh ...

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.

[jd7654]

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 ...

OK, that works, thanks.

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.

[dr. Dan]

@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.

[jamesbond]

@jamesbond: Thanks for looking, and I am only intending to be helpful to someone.

That's the spirit!

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.

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.

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.

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.

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!

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?

Thanks as always.

Much welcome.

[dr. Dan]

@ jamesbond

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.

This was in regard to your suggestion that I compare idle state between the two for battery consumption.

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!

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?

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.

Thanks as always.

Much welcome.