LxPupSc: Woof-CE, Slackware-Current, LXDE build 13-Jun-2020
Hi Peebee,
Can you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot? This is driving me nuts. I don't want a screensnapshot; I want to use the "Up" arrow key for what it is intended for--moving the cursor up. Thus, I want to re-map the key, or disable it, and I cannot figure out which file in lxde/openbox (I'm not in jwm)---is it one of the two files in /root/.config/openbox, either 'lxde-rc.xml' or 'rc.xml'----where I can achieve this? I looked at both files, and I cannot see in them where the Up arrow key has been re-mapped to the mtpaint-screensnapshot launch? I found in jwm where mtpaint-screensnapshot is mapped to the "Print" keyboard key, but like I said, I'm not using jwm. I am always pretty much in the LxPupSc environment the way it comes out of the box, because the way you set everything up is ideal for me like it is. Thanks!
P.S. Thanks for latest LxPupSc delta update.
Can you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot? This is driving me nuts. I don't want a screensnapshot; I want to use the "Up" arrow key for what it is intended for--moving the cursor up. Thus, I want to re-map the key, or disable it, and I cannot figure out which file in lxde/openbox (I'm not in jwm)---is it one of the two files in /root/.config/openbox, either 'lxde-rc.xml' or 'rc.xml'----where I can achieve this? I looked at both files, and I cannot see in them where the Up arrow key has been re-mapped to the mtpaint-screensnapshot launch? I found in jwm where mtpaint-screensnapshot is mapped to the "Print" keyboard key, but like I said, I'm not using jwm. I am always pretty much in the LxPupSc environment the way it comes out of the box, because the way you set everything up is ideal for me like it is. Thanks!
P.S. Thanks for latest LxPupSc delta update.
- Attachments
-
- laptop-keyboard.jpg
- (163.04 KiB) Downloaded 1583 times
belham2 wrote:Hi Peebee,
Can you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot? This is driving me nuts. I don't want a screensnapshot; I want to use the "Up" arrow key for what it is intended for--moving the cursor up. Thus, I want to re-map the key, or disable it, and I cannot figure out which file in lxde/openbox (I'm not in jwm)---is it one of the two files in /root/.config/openbox, either 'lxde-rc.xml' or 'rc.xml'----where I can achieve this? I looked at both files, and I cannot see in them where the Up arrow key has been re-mapped to the mtpaint-screensnapshot launch? I found in jwm where mtpaint-screensnapshot is mapped to the "Print" keyboard key, but like I said, I'm not using jwm. I am always pretty much in the LxPupSc environment the way it comes out of the box, because the way you set everything up is ideal for me like it is. Thanks!
P.S. Thanks for latest LxPupSc delta update.
Just wanted to followup on the question I posted above: figured this much out. One of the files in /root/.config/openbox is the rc.xml file & it seems to be involved in this problem (editing the lxde-rc.xml seems to do nothing). I found an entry in it for 'mtpaint' mapped to key "0x6F", whatever that is. Putting a # before all the lines for this entry mapping stopped 'mtpaint -s' from launching when hitting the "Up" key. But then the "Up" is no longer functional, does nothing. And the bigger problem is, on reboots, my changes to this 'rc.xml' are getting wiped and the launching of 'mtpaint -s' is back again on my "Up" arrow key.
Anyone can steer me in the right direction to fix this permanently? Thank you.
[Edit: fixed, made changes in both lxde-rc.xml & rc.xml, and both held with reboots. Also re-mapped this laptop's F2 thru F6 functions keys: now have working F2 (sound on/off), F3 (sound decrease), F4 (sound increase), F5 (redshiftgui-screen brightness decrease) and F6 (redshiftgui-screen brightness increase). And the "Up" arrow is now blessedly functioning as normal; goodbye to the 'mtpaint -s' launching madness ]
Sorry, I just saw this now. I did connect directly from PCManFM using gvfs and test. I get the same slow 3 minute or more transfer time for the 256Mb savefile. I 'think' that gvfs is the problem but I've checked its versions as well as libsmbclient etc. and they are all either the most recent or updating them gave no change in speeds. Kernel 4.13 did change the default cifs mount to SMB3 from SMB1 but locking my samba server to SMB1, SMB2, or SMB3 gives me no change in the speeds. I normally run with it locked to SMB3 to minimise negotiation and with strict allocate =yes. cli, rsync and Rox-Filer transfers always great no matter what the configuration. Thunar and PCManFM slow. The only common denominator I see is gvfs/kernel interaction but I'm kind of stuck there for now.rcrsn51 wrote:Hi Marv:
Just out of curiosity, if you didn't mount the share in YASSM and let gvfs handle everything, does it make a difference?
Bill
Jim
Last edited by Marv on Tue 03 Oct 2017, 21:59, edited 1 time in total.
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 - I don't see this problem on LxPupSc..... I checked with a pristine frugal install and the keys all worked as expected.belham2 wrote:Can you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot
Was your install using an existing save folder? What had you installed? Have you done any theme changes in LXDE or in JWM?
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
I also have this on my keyboard. I just edit /root/.config/openbox/rc.xml andCan you tell me what I did (or does it come like this?) that causes my laptop's "Up" arrow key (see pic below) to launch mtpaint-screensnapshot?
find the lines that call mtpaint and change it to:
Code: Select all
<keybind key="111">
<action name="Execute">
<startupnotify>
<enabled>true</enabled>
<name>Print Screen</name>
</startupnotify>
<command>mtpaint -s</command>
</action>
</keybind>
Withdrawn - messes up Cups printing....
Interim delta to LxPupSc-17.10.21T-k64
Interim delta to LxPupSc-17.10.21T-k64
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,
I was searching for a recent kernel Puppy and I tried LxPupSc.
My main problem was:
Elantech touchpad not working at all in recent Puppies on an Asus F540S.
Till now I was using Fatdog64 7.10 (kernel 4.4) with an external Usb mouse.
Yesterday I tried LxPusSc, the 1st october release and ta-daaan! Touchpad works OOTB!!
I still have to test if everything works, what I found so far is:
at first wifi connection configuration, using the 'legacy' Network Wizard, a message appears warning that the module rtl8723be is reported NOT to work with WPA encryption. I added it as an exception and then I was able to connect with WPA2 encryption without a hitch. I will test frisbee to see if it complains about WPA as well.
Mouse cursor acts oddly, after opening Light web browser the 'default' pointer changed to an arrow with a grey cirle on its right, and it reverts to simple arrow only on start menu, on hyperlinks or on windows minimise - close buttons. On a console the arrow+circle changes to a vertical stick.
A thing that I love is: if no save session is required, the shutdown process doesn't wake up the sleeping (head parked) hard disc.
On other puppies, even if no partition is mounted and you don't want a to save the first session, a sleeping hard disc is reactivated during the shutdown process and you can hear the disc motor spin up for a second or two and then the PC shuts down. I hate this behaviour and LxPupSc is the only OS that leaves the hard disc off.
Thank you for the great work!
I was searching for a recent kernel Puppy and I tried LxPupSc.
My main problem was:
Elantech touchpad not working at all in recent Puppies on an Asus F540S.
Till now I was using Fatdog64 7.10 (kernel 4.4) with an external Usb mouse.
Yesterday I tried LxPusSc, the 1st october release and ta-daaan! Touchpad works OOTB!!
I still have to test if everything works, what I found so far is:
at first wifi connection configuration, using the 'legacy' Network Wizard, a message appears warning that the module rtl8723be is reported NOT to work with WPA encryption. I added it as an exception and then I was able to connect with WPA2 encryption without a hitch. I will test frisbee to see if it complains about WPA as well.
Mouse cursor acts oddly, after opening Light web browser the 'default' pointer changed to an arrow with a grey cirle on its right, and it reverts to simple arrow only on start menu, on hyperlinks or on windows minimise - close buttons. On a console the arrow+circle changes to a vertical stick.
A thing that I love is: if no save session is required, the shutdown process doesn't wake up the sleeping (head parked) hard disc.
On other puppies, even if no partition is mounted and you don't want a to save the first session, a sleeping hard disc is reactivated during the shutdown process and you can hear the disc motor spin up for a second or two and then the PC shuts down. I hate this behaviour and LxPupSc is the only OS that leaves the hard disc off.
Thank you for the great work!
2nd attempt - ghostscript reverted to 9.21
Interim delta to LxPupSc-17.10.21T-k64
- Kernel 4.13.5-lxpup64
- Slackware-Current to Sat Oct 7 02:53:31 UTC 2017
Interim delta to LxPupSc-17.10.21T-k64
- Kernel 4.13.5-lxpup64
- Slackware-Current to Sat Oct 7 02:53:31 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
LxPupSc-17.10.1T-k64 updated to LxPupSc-17.10.21T-k64 using the delta on the i5 laptop. md5sums ok, hardware summary here. Incorrect cpu current speeds are inxi. I saw the outright refusal to even consider change on github and thought it pretty rude.
Printing to my network (wired) HP4500 all-in-one is fine, SNS wireless connection fine, video resolution & glxgears speed good, touchpad and keyboard mapping good, brightness control and suspends fine. Slimjet 15.1.4.0 from OscarTalks SFS runs correctly. acpi_cpufreq governors checked, schedutil running currently. DVD/CD play not checked yet.
Two things of note on my samba throughput tests.
One is that a 256Mb savefile transfer using pcmanfm 'drag to copy' and a gvfs connection made directly from pcmanfm now matches the rsync speed at 37 seconds. Just done twice but with exactly the same numbers. That's great!
The second is that YASSM 4.1 and YASSM 2.9 no longer work. The search functions in 2.9 work but the mount fails in both. Worked fine in 17.10.1 and in 17.10.21 with the 4.13.4 kernel from 17.10.1 swapped into 17.10.21. It is a mount.cifs failure, summary below:
Edit: I just went through the changelog for 4.13.5. There were a LOT of changes wrt CIFS and SMB, some of them walking back some of the SMB changes made recently. I'd say just let it settle, there's a pretty good chance it'll get sorted in one of the next releases. Took out a couple of my maybe too flippant remarks while I was here.
Edit2: Just to add, I locked to and unlocked my samba server from SMB3 and tried the various security options (sec=ntlm,ntlmv2,ntlmssp) in the mount.cifs command line. All with the same result. Also had a go in XFCE-xenialpup64 swapping in this 4.13.5 64b kernel with the same results. That pup has the same version 6.7 mount.cifs.
All for now,
Code: Select all
# inxi -F
System: Host: puppypc2638 Kernel: 4.13.5-lxpup64 x86_64 (64 bit)
Desktop: LXDE (Openbox 3.6.1) Distro: LxPup-Sc 17.10.21
Machine: Device: laptop System: FUJITSU product: LIFEBOOK S761 serial: R1Y00453
Mobo: FUJITSU model: FJNB225
UEFI [Legacy]: FUJITSU // Phoenix v: Version 1.17 date: 03/14/2012
Battery CMB1: charge: 65.0 Wh 97.0% condition: 67.0/67.0 Wh (100%)
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
Graphics: Card: Intel 2nd Generation Core Processor Family Integrated Graphics Controller
Display Server: X.org 1.19.4 drivers: intel (unloaded: modesetting,vesa)
tty size: 80x24 Advanced Data: N/A for root
Audio: Card Intel 6 Series/C200 Series Family High Definition Audio Controller
driver: snd_hda_intel
Sound: Advanced Linux Sound Architecture v: k4.13.5-lxpup64
Network: Card-1: Intel 82579LM Gigabit Network Connection (Lewisville)
driver: e1000e
IF: eth0 state: down mac: b0:99:28:cf:30:51
Card-2: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express)
driver: ath9k
IF: wlan0 state: up mac: e0:ca:94:6f:ee:ee
Drives: HDD Total Size: 64.0GB (25.5% used)
ID-1: /dev/sda model: SAMSUNG_SSD_830 size: 64.0GB
RAID: No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors: None detected - is lm-sensors installed and configured?
Info: Processes: 144 Uptime: 11 min Memory: 273.6/2778.6MB
Client: Shell (bash) inxi: 2.3.8
#
Two things of note on my samba throughput tests.
One is that a 256Mb savefile transfer using pcmanfm 'drag to copy' and a gvfs connection made directly from pcmanfm now matches the rsync speed at 37 seconds. Just done twice but with exactly the same numbers. That's great!
The second is that YASSM 4.1 and YASSM 2.9 no longer work. The search functions in 2.9 work but the mount fails in both. Worked fine in 17.10.1 and in 17.10.21 with the 4.13.4 kernel from 17.10.1 swapped into 17.10.21. It is a mount.cifs failure, summary below:
Code: Select all
LxPup 17.10.21 with stock 4.13.5 kernel (YASSM 4.1 fails) (manual mount fails)
# mount.cifs //192.168.10.17/HouseShares /mnt/tmp
Password for root@//192.168.10.17/HouseShares:
mount error(5): Input/output error
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
#
LxPupSc 17.10.1 stock (YASSM 4.1 works) (files mount correctly manually)
# mount.cifs //192.168.10.17/HouseShares /mnt/tmp
Password for root@//192.168.10.17/HouseShares:
#
LxPupSc 17.10.21 with 4.13.4 kernel swapped in (YASSM 4.1 works) (files mount correctly manually)
# mount.cifs //192.168.10.17/HouseShares /mnt/tmp
Password for root@//192.168.10.17/HouseShares:
#
Edit2: Just to add, I locked to and unlocked my samba server from SMB3 and tried the various security options (sec=ntlm,ntlmv2,ntlmssp) in the mount.cifs command line. All with the same result. Also had a go in XFCE-xenialpup64 swapping in this 4.13.5 64b kernel with the same results. That pup has the same version 6.7 mount.cifs.
All for now,
Last edited by Marv on Sun 08 Oct 2017, 13:27, edited 1 time in total.
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.
Interim delta to LxPupSc-17.10.22T-k64
- Kernel 4.13.6-lxpup64
- Slackware-Current to Tue Oct 10 18:08:31 UTC 2017
- Kernel 4.13.6-lxpup64
- Slackware-Current to Tue Oct 10 18:08:31 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
Updated my 17.10.21 install referenced above to 17.10.22. No adverse changes seen in a brief test. No resolution yet in the mount.cifs/Cifs issue discussed 2 and 3 posts above. Watchful waiting advised.peebee wrote:Interim delta to LxPupSc-17.10.22T-k64
- Kernel 4.13.6-lxpup64
- Slackware-Current to Tue Oct 10 18:08:31 UTC 2017
Last edited by Marv on Thu 19 Oct 2017, 20:28, edited 1 time in total.
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.
Interim delta to LxPupSc-17.10.23T-k64
- Kernel 4.13.8-lxpup64
- Slackware-Current to Fri Oct 20 04:44:44 UTC 2017 including wpa-supplicant security updates
- Kernel 4.13.8-lxpup64
- Slackware-Current to Fri Oct 20 04:44:44 UTC 2017 including wpa-supplicant security updates
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
chromium_62.0.3202.62+pepper_27.0.0.170_lxsc_spot.sfs
is available for LxPupSc
but as it is RUN-AS-SPOT
it won't become the default Chromium download for the time being.
is available for LxPupSc
but as it is RUN-AS-SPOT
it won't become the default Chromium download for the time being.
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 17.10.24T
Kernel 4.13.9
Slackware Current to Tue Oct 24 05:31:18 UTC 2017
Addition of apulse improves Light's playing of Youtube videos
Kernel 4.13.9
Slackware Current to Tue Oct 24 05:31:18 UTC 2017
Addition of apulse improves Light's playing of Youtube videos
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
LxPupSc-17.11.1T-k64
LxPupSc-17.11.1T-k64 is a 32-bit woof-ce 'testing' branch build with a 64-bit kernel (therefore only compatible with 64-bit capable processors)
LxPupSc-17.11.1T-k64.iso {devx} - (devx does not include kernel sources or headers) {kernel 4.13.10-lxpup64 sources}
iso md5 = 9bb8594c0796c4b9503e11a0ebcda73a
Delta from 17.10.1T is available
- kernel 4.13.10 64-bit (alternative 32-bit kernels 3.16.x 4.4.x & 4.9.x also available - all need firmware in the fdrv)
- Made from Slackware-Current as of Tue Oct 31 23:53:38 UTC 2017
- BUILD_FROM_WOOF='testing;5f4e35ba;2017-10-31 22:27:46 +0100'
- web browser in adrv is light-48.0
- firmware is in fdrv
- alternative fall-back xorg is in ydrv (no need to install unless needed)
**N.B. the 64-bit kernel means that any kernel drivers have to be built in a true 64-bit system - slacko64 with the LxPupSc kernel and it's own devx is suggested but use the kernel sources above
Woof-CE build repository is: http://smokey01.com/peebee/slackocurrent/
Chromium, Firefox, Palemoon and Seamonkey are in the repository and installable via Internet -> Get Web Browser
The versions of the browsers as of 30-oct-2017 with their md5sums are:
chromium_62.0.3202.75+pepper_27.0.0.183 RUN-AS-SPOT :2b639fdbcdc680da3901522cdd3fa187
firefox-52.4.1esr :97451d4fdee2208a4fe92815a5b9678c
palemoon-27.5.1 :c03c82981e8a110b0d5b199034d14b2d
seamonkey-2.48 :05b91afef8b60bda21343a45da0aae49
firefox-56, slimjet, vivaldi and min are also available
LxPupSc-17.11.1T-k64.iso {devx} - (devx does not include kernel sources or headers) {kernel 4.13.10-lxpup64 sources}
iso md5 = 9bb8594c0796c4b9503e11a0ebcda73a
Delta from 17.10.1T is available
- kernel 4.13.10 64-bit (alternative 32-bit kernels 3.16.x 4.4.x & 4.9.x also available - all need firmware in the fdrv)
- Made from Slackware-Current as of Tue Oct 31 23:53:38 UTC 2017
- BUILD_FROM_WOOF='testing;5f4e35ba;2017-10-31 22:27:46 +0100'
- web browser in adrv is light-48.0
- firmware is in fdrv
- alternative fall-back xorg is in ydrv (no need to install unless needed)
**N.B. the 64-bit kernel means that any kernel drivers have to be built in a true 64-bit system - slacko64 with the LxPupSc kernel and it's own devx is suggested but use the kernel sources above
Woof-CE build repository is: http://smokey01.com/peebee/slackocurrent/
Chromium, Firefox, Palemoon and Seamonkey are in the repository and installable via Internet -> Get Web Browser
The versions of the browsers as of 30-oct-2017 with their md5sums are:
chromium_62.0.3202.75+pepper_27.0.0.183 RUN-AS-SPOT :2b639fdbcdc680da3901522cdd3fa187
firefox-52.4.1esr :97451d4fdee2208a4fe92815a5b9678c
palemoon-27.5.1 :c03c82981e8a110b0d5b199034d14b2d
seamonkey-2.48 :05b91afef8b60bda21343a45da0aae49
firefox-56, slimjet, vivaldi and min are also available
- Attachments
-
- Screenshot.png
- (121.57 KiB) Downloaded 1620 times
Last edited by peebee on Wed 01 Nov 2017, 19:38, edited 3 times 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
Re: LxPupSc-17.11.1T-k64
peebee wrote:LxPupSc-17.11.1T-k64 is a 32-bit build with a 64-bit kernel (therefore only compatible with 64-bit capable processors)
**N.B. the 64-bit kernel means that any kernel drivers have to be built in a true 64-bit system - slacko64 with it's own devx is suggested but use the kernel sources above
Hi Peebee,
Applied delta from 17.10.1 to 17.11.1, all seemed to go fine. Took resulting 17.11.1 ISO, clicked on it, and copied over to the existing 17.10.23 'frugal' folder the new fdrv, ydrv, zdrv, puppy, initrd & vmlinuz. Corrected the grub4dos mennu.lst, and with your chromium.sfs in there too, all seems to running good. Thanks!
Hey, Peebee, I also have a question, and please excuse any stupidityignorance in not understanding this . Every time I read a release post of one of LxPupSc, I am struck by the two lines I highlighted above. Since these creations cannot run on 32-bit processors, without the user going through a bit of gymnastics (which, to be honest, I cannot see the vast majority of users doing), what is the reasoning behind not just going to a full "64-bit" release or forgoing all things related to 32-bit? Is it because of software availability, or kernels and/or drivers? Or is it because the way you set things up for LxPupSc make it run or operate 'faster' than 64-bit OSes? Or what else...???? I do know if you went to full '64-bit' it sure would make the browser situation much easier, as people could just download themselves the 64-bit browser they llike and/or want to use. In my mind, I think I asked this once before a year or two ago, but I'll be danged if I can now remember and/or find the post when you explained it to me. Thanks for any quick explanation.
- Attachments
-
- LxPupSc_17.11.1.png
- (72.33 KiB) Downloaded 1556 times
Re: LxPupSc-17.11.1T-k64
Very mundane....belham2 wrote:what is the reasoning behind not just going to a full "64-bit" release or forgoing all things related to 32-bit?
I like 32-bit because all 32-bit systems are basically similar architecture wrt lib directories and there is a wealth of 32-bit puppy applications available on the forum so I'm free to pick and choose components from multiple sources....
I don't like 64-bit for the converse reason that there seem to be many lib64 architectures which are mutually incompatible and therefore apps are specific to build (viz: fatdog, slacko, xenial...)
I had problems with the 32-bit kernel 4.13 builds as they crashed on some laptops when inserting cd/dvds - the 64-bit builds based on BarryK's config don't so crash and seem to work fine with 32-bit systems so that is the way I went - if I could fix the 32-bit config to fix the crash I'd go back to 32-bit pae.
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
efi 64bit and 32bit kernels
peebee, it suits me fine you use a 64bit kernel because of another reason:
My new machine is 64bit EFI.
64 bit EFI cannot boot 32bit kernels; 64bit kernels I can simply add to the grub.cfg and they will (efi)boot.
If I want to boot a 32bit kernel, I have to insert a usb-stick with a legacy/grub4dos booting installation on it to boot from that.
(noob) Question:
Could I swap a 64bit-kernel (and zdrv) into a 32bit build just like that? Or is there more to it?
My new machine is 64bit EFI.
64 bit EFI cannot boot 32bit kernels; 64bit kernels I can simply add to the grub.cfg and they will (efi)boot.
If I want to boot a 32bit kernel, I have to insert a usb-stick with a legacy/grub4dos booting installation on it to boot from that.
(noob) Question:
Could I swap a 64bit-kernel (and zdrv) into a 32bit build just like that? Or is there more to it?
Interim delta +1 to LxPupSc-17.11+1T-k64.iso is here already....
- kernel 4.13.11
- openssl-1.0.2m and new Cups from Slackware Current
Slight different approach to interim deltas - no longer a version update - makes life easier all round - just generate the new .iso from the .delta, open the new .iso and overwrite the updated files in your frugal install - reboot.
In this case because its a kernel bump the 3 files to overwrite are puppy*.sfs, zdrv*.sfs and vmlinuz
- kernel 4.13.11
- openssl-1.0.2m and new Cups from Slackware Current
Slight different approach to interim deltas - no longer a version update - makes life easier all round - just generate the new .iso from the .delta, open the new .iso and overwrite the updated files in your frugal install - reboot.
In this case because its a kernel bump the 3 files to overwrite are puppy*.sfs, zdrv*.sfs and vmlinuz
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