Neither Yassm nor PcManFM have any trouble connecting and once connected I see the behavior irrespective of which I've used. I also see it in XFCE4/Thunar based pups.The NAS box is wired but the clients are wireless. I'll try it with a wired client but because so far it seems pup invariant at both the server side and client side, seems slightly a function of drive and connection type used for the shares on the server box, and never shows up for multiple small files, even adding to the .5 Gb total, I lean toward a cache issue. At any rate, it's more a natter than a problem and there are several variables to sort out so I will eventually figure it out but at it's own pace. I do use the attached shares multiple times in a day and just hit Yassm mount and go. Small to 50Mb sized files then go very very quickly and reliably. It's just the bigger iso transfers that do eventually complete but crawl toward the end. In general the partitions I transfer isos to and from are EXT2, with an occasional larger SFS to or from a fat32 partition.rcrsn51 wrote:I'm guessing that this is over WiFi? I have had problems with this in the past.Marv wrote:I am using Yassm 4.1 to connect to the NAS box currently running 17.08.24T and X-Slacko 4.3 alternately as I chase a large (0.5 Gb +) file transfer quirk, probably disc cache related.
It isn't a YASSM issue - YASSM just uses the mounting tools provided by the host Puppy. After that, it's the job of the Puppy file manager and the target Samba server to maintain a connection.
I found this to be fragile over WiFi with large files, even with ROX as the file manager. Do the built-in PcManFm tools work any better?
[Edit:] However, I notice that some Puppies are still using the mountcifs-1.5.pet package from 2011.
LxPupSc: Woof-CE, Slackware-Current, LXDE build 13-Jun-2020
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Hi mistfiremistfire wrote:@peebee you forgot to compile a 32-bit version of that kernel.
My 32-bit builds of >4.10 seem to have problems with cd's on laptops so I'll be sticking to 64-bit builds - which can be used with 32-bit systems - have you tried the 64-bit kernel??
Last edited by peebee on Mon 11 Sep 2017, 22:27, edited 1 time in total.
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Interim delta to LxPupSc-17.09.22T-k64
- Kernel 4.13.1-lxpup64
- Slackware-Current to Fri Sep 8 17:56:01 UTC 2017
- updated adrv and fdrv
- some tweaks to build system
n.b. I've started adding some build notes to post #2
- Kernel 4.13.1-lxpup64
- Slackware-Current to Fri Sep 8 17:56:01 UTC 2017
- updated adrv and fdrv
- some tweaks to build system
n.b. I've started adding some build notes to post #2
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Interim delta to LxPupSc-17.09.23T-k64
- Kernel 4.13.2-lxpup64
- Slackware-Current to Tue Sep 12 22:18:51 UTC 2017
- Kernel 4.13.2-lxpup64
- Slackware-Current to Tue Sep 12 22:18:51 UTC 2017
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
-
- Posts: 37
- Joined: Tue 01 Jan 2013, 19:23
- Location: Germany, Berlin
@peebee 21T updated to 22T, then to 23T on the Fujitsu S761 referenced above. Nothing to report wrt sound, connection, video resolution and speed, CD & DVD detection, Redshift etc. All-in-all it continues to be rock solid here. The S761 computer at the farm is a few versions back but post 64b kernel and I continue to get raves from Mary on it.
I did notice and don't really note when it started, that running acpi-cpufreq with a conservative governor that the CPU/Fan control seems fine but both inxi and hardinfo report all CPUs at a fixed high speed (2491). The fan use, the /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq value (800 right now), and the 'time in state', below, seem to indicate that the governor is working correctly.inxi reports:
My hardware or a general issue?
@rcrsn51 I pretty much have the NAS box transfers sorted to my satisfaction. The chief culprit was the wired/wireless router (an older Buffalo Airstation running Tomato firmware) throughput on a local file transfer. WAN to LAN was fine, wireless connections were rock solid, wired throughput ok but mediocre, but I bumped the wireless to wired local throughput by 6X swapping in a hardly state of the art TP-Link C50 router. Backing up a 250MB iso to the NAS box running samba went from a flakey 3 minutes to a solid 30 second transfer using rsync to check. I can happily live with that. Could have been either CPU speed or available memory for buffering in the router.
I did notice and don't really note when it started, that running acpi-cpufreq with a conservative governor that the CPU/Fan control seems fine but both inxi and hardinfo report all CPUs at a fixed high speed (2491). The fan use, the /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq value (800 right now), and the 'time in state', below, seem to indicate that the governor is working correctly.
Code: Select all
2500000 1073
2000000 1382
1800000 1585
1600000 2956
1400000 5669
1200000 9466
1000000 17012
800000 701498
Code: Select all
CPU: Dual core Intel Core i5-2520M (-HT-MCP-) cache: 3072 KB
clock speeds: max: 2501 MHz 1: 2491 MHz 2: 2491 MHz 3: 2491 MHz
4: 2491 MHz
@rcrsn51 I pretty much have the NAS box transfers sorted to my satisfaction. The chief culprit was the wired/wireless router (an older Buffalo Airstation running Tomato firmware) throughput on a local file transfer. WAN to LAN was fine, wireless connections were rock solid, wired throughput ok but mediocre, but I bumped the wireless to wired local throughput by 6X swapping in a hardly state of the art TP-Link C50 router. Backing up a 250MB iso to the NAS box running samba went from a flakey 3 minutes to a solid 30 second transfer using rsync to check. I can happily live with that. Could have been either CPU speed or available memory for buffering in the router.
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Really bad news.
Intel Power-state frequency scaling driver is faulty since three years, that's known.
But we never had before trouble with acpi-cpufreq driver which is used in this case
I can't detect a frequency regulation.
Usage of governor powersave let the frequency stick at 800 Mhz all the time.
Under useage of governor performance frequency is sticking between 3800-3900 Mhz ( but 3100 Mhz is max frequenzy for the cpu)
under conservative frequency almost always at 800 Mhz and under ondemand absolutely indefinable.
In other words, cpu frequency scaling doesn't work.
It's not recommended to use this kernel in my opinion.
@peebee
Nevertheless very good job
Thank you very much
update:
LxPupSC-17.09.22T-k64
Kernel 4.13.1
Intel Power-state frequency scaling driver is faulty since three years, that's known.
But we never had before trouble with acpi-cpufreq driver which is used in this case
I can't detect a frequency regulation.
Usage of governor powersave let the frequency stick at 800 Mhz all the time.
Under useage of governor performance frequency is sticking between 3800-3900 Mhz ( but 3100 Mhz is max frequenzy for the cpu)
under conservative frequency almost always at 800 Mhz and under ondemand absolutely indefinable.
In other words, cpu frequency scaling doesn't work.
It's not recommended to use this kernel in my opinion.
@peebee
Nevertheless very good job
Thank you very much
update:
LxPupSC-17.09.22T-k64
Kernel 4.13.1
Hi norgo, what hardware are you running?
I looked again at the contents of the control registers above in both 21T and 23T both at system idle and using glxgears to goad the cpus into action. In both pups and using both ondemand and conservative govs, the actual contents of the system control registers on my hardware (all intel 2nd gen i3 laptop referenced above) do seem to behave in a governed manner. The fan and glxgears FPS both seem to confirm this.
In both pups above the inxi, hardinfo, and pupsysinfo reporting doesn't reflect this. It is stuck at 2491 out of 2501 for my CPUs. Seems like a reporting issue from here, unlike the Intel Power-state frequency scaling driver fiasco on most hardware. I'll go a bit further back and see what I see as well as looking at some different hardware.
Update1: LxPup-Sc 17.07.1 - Linux 4.11.8-lxpup-32-pae i686 tested on the same hardware and reporting (Conservative governor and PupSusinfo used) is correct. Same drill as above, check at idle, use glxgears to raise CPU speed, check system registers and update report. Nothing between done yet.
Update2: LxPup-Sc 17.08.1 - Linux 4.12.4-lxpup64 x86_64, IIRC pretty much the first 64b kernel other than swap-ins to test, is reporting the CPU speed correctly. Tested exactly as above.
Update3: Went back and rechecked LxPup-Sc 17.09.23 - Linux 4.13.2-lxpup64 x86_64, pristine frugal boot with only timezone, firewall and SNS wireless connection (no adrv used, posting from portable QtWeb). No change, it fails to report correctly.
A pristine frugal boot of LxPup-Sc 17.09.1 - Linux 4.12.10-lxpup64 x86_64 reports correctly. So, up to 17.09.1 is ok, 17.09.21 is not.
Cheers,
I looked again at the contents of the control registers above in both 21T and 23T both at system idle and using glxgears to goad the cpus into action. In both pups and using both ondemand and conservative govs, the actual contents of the system control registers on my hardware (all intel 2nd gen i3 laptop referenced above) do seem to behave in a governed manner. The fan and glxgears FPS both seem to confirm this.
In both pups above the inxi, hardinfo, and pupsysinfo reporting doesn't reflect this. It is stuck at 2491 out of 2501 for my CPUs. Seems like a reporting issue from here, unlike the Intel Power-state frequency scaling driver fiasco on most hardware. I'll go a bit further back and see what I see as well as looking at some different hardware.
Update1: LxPup-Sc 17.07.1 - Linux 4.11.8-lxpup-32-pae i686 tested on the same hardware and reporting (Conservative governor and PupSusinfo used) is correct. Same drill as above, check at idle, use glxgears to raise CPU speed, check system registers and update report. Nothing between done yet.
Update2: LxPup-Sc 17.08.1 - Linux 4.12.4-lxpup64 x86_64, IIRC pretty much the first 64b kernel other than swap-ins to test, is reporting the CPU speed correctly. Tested exactly as above.
Update3: Went back and rechecked LxPup-Sc 17.09.23 - Linux 4.13.2-lxpup64 x86_64, pristine frugal boot with only timezone, firewall and SNS wireless connection (no adrv used, posting from portable QtWeb). No change, it fails to report correctly.
A pristine frugal boot of LxPup-Sc 17.09.1 - Linux 4.12.10-lxpup64 x86_64 reports correctly. So, up to 17.09.1 is ok, 17.09.21 is not.
Cheers,
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
post superceded...
Last edited by peebee on Sat 16 Sep 2017, 19:18, edited 1 time in total.
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Kernel was changed from 4.12.10 to 4.13.0 at 17.09.21....
Reverting to 4.12.10.... inxi -C shows varying cpu speeds with 17.09.23
So is a kernel problem....
Config did change between 4.12.10 and 4.13.x - hibernation was enabled as requested by @mistfire - perhaps I should revert that change??
Reverting to 4.12.10.... inxi -C shows varying cpu speeds with 17.09.23
So is a kernel problem....
Config did change between 4.12.10 and 4.13.x - hibernation was enabled as requested by @mistfire - perhaps I should revert that change??
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
OK - rebuilt k4.13.2 without hibernation config change - same behaviour so that isn't the culprit....
Looks like it's a 4.13 kernel problem but google doesn't produce any clues in my searches....
Options seem to be:
- live with it - are there any downsides to this?
- revert to k4.12.10 from 17.07.1
- use one of the alternative 32-bit kernels 4.9.x etc.
Looks like it's a 4.13 kernel problem but google doesn't produce any clues in my searches....
Options seem to be:
- live with it - are there any downsides to this?
- revert to k4.12.10 from 17.07.1
- use one of the alternative 32-bit kernels 4.9.x etc.
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Since this is 'testing' and I see no other problems with the 4.13 I say live with it with a warning in the thread. 4.12.10 would be my second choice. The problem is that /proc/cpuinfo is not being generated correctly by the kernel. Here is the core of a watch script that does work in 4.13.peebee wrote:OK - rebuilt k4.13.2 without hibernation config change - same behaviour so that isn't the culprit....
Looks like it's a 4.13 kernel problem but google doesn't produce any clues in my searches....
Options seem to be:
- live with it - are there any downsides to this?
- revert to k4.12.10 from 17.07.1
- use one of the alternative 32-bit kernels 4.9.x etc.
Code: Select all
#!/bin/sh
# Fails in 4.13 kernel
# lxterminal --geometry=27x3 --title=CPU_watch -e watch -n1 -t "cat /proc/cpuinfo | grep "^[c]pu MHz""
# Works on cpu0, could be expanded
lxterminal --geometry=27x3 --title=CPU_watch -e watch -n1 -t "cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq"
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Thanks Jim - that was the clue that google wanted ....Marv wrote:The problem is that /proc/cpuinfo is not being generated correctly by the kernel.
https://www.phoronix.com/scan.php?page= ... Management
http://lkml.iu.edu/hypermail/linux/kern ... 01366.html- x86 systems will no longer try to export their current CPU frequency to /proc/cpuinfo. There's also a way to rework how the CPU frequency is exported via sysfs too, using the registers for computing the current frequency rather than relying upon the CPUFreq driver.
- Stop trying to export the current CPU frequency via /proc/cpuinfo
on x86 as that is inaccurate and confusing (Len Brown).
- Rework the way in which the current CPU frequency is exported by
the kernel (over the cpufreq sysfs interface) on x86 systems with
the APERF and MPERF registers by always using values read from
these registers, when available, to compute the current frequency
regardless of which cpufreq driver is in use (Len Brown).
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Hi peebee,
In your next kernel build could you changeto
? In reading about the power management changes in 4.13 I came across it. schedutil is supposed to be the replacement for conservative, is actively supported, and what benchmarks I've seen look quite good.
In your next kernel build could you change
Code: Select all
# CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set
Code: Select all
CONFIG_CPU_FREQ_GOV_SCHEDUTIL=m
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
connecting wifi
Peebee
I am on a new laptop. I tried fatdog64, but soon moved to the RC's for xenialpup and slacko. I even tried debian stretch and slackware current (live).
Recently I turned to your LxPupSc which is excellent for new machines, not to say the best. It also brings back a bit the feel of saluki/carolina to me; I don't know why exactly. Thank you for this.
On version 17.08.23 I had to choose "CRD: 00 UNSET" for wifi. I still had to link /usr/local/simple_network_setup/rc.network in /root/Startup/ to have connection on startup. I also tried "CRD: BE Belgium", but automatic startup did not work, not even with the link, and in SNS "connect now" did not work (the profile seemed lost), so SNS had to scan for wifi connections every time again.
I am on version 17.09.21 now, and the above now works fine: "CRD: BE Belgium", persistence in SNS and even automatic connection on startup (without the link in ~/Startup).
However, the connection takes a long time. I had discovered before on version 17.08.23, executing rc.network in terminal with --verbose, that with "CRD: BE Belgium" /usr/sbin/connectwizard_crd is executed and the following errors occur:
/usr/sbin/connectwizard_crd: line 15: iw: command not found
/usr/sbin/connectwizard_crd: line 21: iw: command not found
....
The second error is repeated a lot of times and this takes a long time.
I comment this line out fttb, because I do not know how to correct the command.
EDIT: I cannot say connection time is shorter though: it remains around 1 minute.
Just one other thing puzzles me: I found another rc.network file at /etc/rc.d/
I am on a new laptop. I tried fatdog64, but soon moved to the RC's for xenialpup and slacko. I even tried debian stretch and slackware current (live).
Recently I turned to your LxPupSc which is excellent for new machines, not to say the best. It also brings back a bit the feel of saluki/carolina to me; I don't know why exactly. Thank you for this.
On version 17.08.23 I had to choose "CRD: 00 UNSET" for wifi. I still had to link /usr/local/simple_network_setup/rc.network in /root/Startup/ to have connection on startup. I also tried "CRD: BE Belgium", but automatic startup did not work, not even with the link, and in SNS "connect now" did not work (the profile seemed lost), so SNS had to scan for wifi connections every time again.
I am on version 17.09.21 now, and the above now works fine: "CRD: BE Belgium", persistence in SNS and even automatic connection on startup (without the link in ~/Startup).
However, the connection takes a long time. I had discovered before on version 17.08.23, executing rc.network in terminal with --verbose, that with "CRD: BE Belgium" /usr/sbin/connectwizard_crd is executed and the following errors occur:
/usr/sbin/connectwizard_crd: line 15: iw: command not found
/usr/sbin/connectwizard_crd: line 21: iw: command not found
....
The second error is repeated a lot of times and this takes a long time.
I comment this line out fttb, because I do not know how to correct the command.
EDIT: I cannot say connection time is shorter though: it remains around 1 minute.
Just one other thing puzzles me: I found another rc.network file at /etc/rc.d/
Interim delta to LxPupSc-17.09.24T-k64
- Kernel 4.13.3-lxpup64 including @Marv's requested CONFIG_CPU_FREQ_GOV_SCHEDUTIL
- Slackware-Current to Tue Sep 19 20:49:07 UTC 2017
iw has been added as reported by @foxpup
- Kernel 4.13.3-lxpup64 including @Marv's requested CONFIG_CPU_FREQ_GOV_SCHEDUTIL
- Slackware-Current to Tue Sep 19 20:49:07 UTC 2017
iw has been added as reported by @foxpup
Last edited by peebee on Thu 21 Sep 2017, 20:06, edited 1 time in total.
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
23T updated to 24T using the delta. md5sum correct, nothing of note in the update so far. Radkys PupSysInfo 2.7.3 now reports CPU speeds correctly in 4.13 kernels, as does the little cpuwatch I used in my post above (cpu* replaces cpu0). Inxi, hardinfo and wcpufreq don't as yet. The schedutil governor now shows up and runs (Thanks!). It will take a bit to see how I like it but at first glance I think it is a bit more 'adaptive' than conservative. The difference in PupSysinfo and cpuwatch speeds is because the PupSysInfo information was grabbed before starting glxgears and the cpuwatch is dynamic with a 1 sec grab time.
Update: radkys fix applied to wcpufreq also allows it to display speeds correctly. I have a .diff but don't know who maintains that.
Cheers,
Update: radkys fix applied to wcpufreq also allows it to display speeds correctly. I have a .diff but don't know who maintains that.
Cheers,
- Attachments
-
- screenshot.png
- (204.7 KiB) Downloaded 1351 times
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
Thanks @Marv - wcpufreq was apparently developed by tazoc who sadly hasn't been on the forum since 2013....Marv wrote:Update: radkys fix applied to wcpufreq also allows it to display speeds correctly. I have a .diff but don't know who maintains that.
Cheers,
The .pet is in noarch-official so if you send me the changes I'll upload a new version....
Cheers
peebee
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Anybody else noticed that the 64-bit kernel makes lsmod report module size differently to the 32-bit kernel? First 64-bit 'oddity' that I've noticed - doesn't seem to have any further ramifications??
Kernel 4.9.50 32-bit gives:Kernel 4.13.3 64bit gives:
Kernel 4.9.50 32-bit gives:
Code: Select all
Module Size Used by
iptable_filter 1379 0
ip_tables 9625 1 iptable_filter
snd_hda_codec_via 9338 1
snd_hda_codec_generic 49158 1 snd_hda_codec_via
rt2800usb 16439 0
rt2x00usb 7961 1 rt2800usb
rt2800lib 69770 1 rt2800usb
rt2x00lib 32058 3 rt2800lib,rt2800usb,rt2x00usb
mac80211 328553 3 rt2800lib,rt2x00lib,rt2x00usb
cfg80211 220211 2 rt2x00lib,mac80211
crc_ccitt 1195 1 rt2800lib
rfkill 8235 1 cfg80211
usblp 9474 0
snd_pcsp 6269 0
nouveau 1313442 2
mxm_wmi 1203 1 nouveau
wmi 6184 2 mxm_wmi,nouveau
i2c_algo_bit 4516 1 nouveau
ttm 64138 1 nouveau
drm_kms_helper 99176 1 nouveau
k10temp 2160 0
syscopyarea 2990 1 drm_kms_helper
hwmon 6646 2 k10temp,nouveau
Code: Select all
Module Size Used by
iptable_filter 16384 0
ip_tables 24576 1 iptable_filter
cpufreq_ondemand 16384 2
snd_hda_codec_via 20480 1
snd_hda_codec_generic 53248 1 snd_hda_codec_via
arc4 16384 2
joydev 20480 0
rt2800usb 24576 0
rt2x00usb 20480 1 rt2800usb
rt2800lib 90112 1 rt2800usb
rt2x00lib 40960 3 rt2800lib,rt2800usb,rt2x00usb
mac80211 303104 3 rt2800lib,rt2x00lib,rt2x00usb
cfg80211 221184 2 rt2x00lib,mac80211
usblp 20480 0
rfkill 20480 1 cfg80211
crc_ccitt 16384 1 rt2800lib
nouveau 1359872 2
k10temp 16384 0
mxm_wmi 16384 1 nouveau
wmi 20480 2 mxm_wmi,nouveau
video 32768 1 nouveau
hwmon 16384 2 k10temp,nouveau
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64