Thanks Toni, I am currently using porteus kernel per your instructions. Very nice and easy to do. Unfortunately, it proves my theory wrong (hmmm, my theories are currently letting me down, one after the other! I was genuinely surprised on this occasion) - mplayer still consuming same amount of CPU... But now I'm confused because the old Porteus-Wheezy of Dec 2013 definitely resulted in mplayer using one third of that CPU on this machine. So why, I wonder is that not the case in DebianDog with the Porteus kernel (I assume it is the same kernel)? I'm running out of ideas. I presume Xorg is the same?saintless wrote:Hi, William.mcewanw wrote:...But how do I get these modules for DebianDog or can I use that old Portues kernel/modules/firmware somehow on latest DebianDog - I think that would solve it for me?! :-) Might well also solve similar issue for anyone else with a problem when that /lib/modules/kernel/drivers/char/agp directory doesn't exist on their system but instead all built into the official Debian kernel.
You can have this very easy:
Download 3.9.11 porteus archive and extract it inside /live
Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy
github mcewanw
Hi, William.
The kernel is the same as the one from Porteus Wheezy on the site now. I don't know about xorg in first Porteus-Wheezy.. Only Fred can answer in details about this. It was replaced with new one here later:
http://smokey01.com/saintless/Porteus-Wheezy/
Ally is collecting all versions. You can check out here for older version:
https://ia801005.us.archive.org/27/item ... e-Live-CD/
Edit: If you like to confirm if the kernel is the real problem or not you can make easy test like this one:
http://murga-linux.com/puppy/viewtopic. ... 138#764921
Download this default DebianDog kernel separate archive and extract it in /live.
http://smokey01.com/saintless/DebianDog ... el-486.zip
Then rename GuyDog main module to 01-filesystem.squashfs and replace the original one. Use live-boot-2. I haven't test porteus-boot this way yet.
Toni
The kernel is the same as the one from Porteus Wheezy on the site now. I don't know about xorg in first Porteus-Wheezy.. Only Fred can answer in details about this. It was replaced with new one here later:
http://smokey01.com/saintless/Porteus-Wheezy/
Ally is collecting all versions. You can check out here for older version:
https://ia801005.us.archive.org/27/item ... e-Live-CD/
Edit: If you like to confirm if the kernel is the real problem or not you can make easy test like this one:
http://murga-linux.com/puppy/viewtopic. ... 138#764921
Download this default DebianDog kernel separate archive and extract it in /live.
http://smokey01.com/saintless/DebianDog ... el-486.zip
Then rename GuyDog main module to 01-filesystem.squashfs and replace the original one. Use live-boot-2. I haven't test porteus-boot this way yet.
Toni
Hi William,
I had a look at the initrd3.xz and noticed there's unneeded module loading in the linuxrc script (it's only needed for use with the debian stable kernel)
I took it out, so here's different initrd3.xz, maybe it helps.
EDIT: Link removed.
It should be the same now as the initrd from first porteus-wheezy apart from the changes that are made to use .squashfs instead of .xzm.
Btw, adding a module at boot always gives more pressure on the system, so that could also be the reason for more cpu usage.
To really compare better: do a remaster to use only one squashfs.
EDIT: Stupid me, just looked at it better: there are no kernel modules inside initrd3.xz, so nothing to load. Removed the link because it's useless.
Fred
I had a look at the initrd3.xz and noticed there's unneeded module loading in the linuxrc script (it's only needed for use with the debian stable kernel)
I took it out, so here's different initrd3.xz, maybe it helps.
EDIT: Link removed.
It should be the same now as the initrd from first porteus-wheezy apart from the changes that are made to use .squashfs instead of .xzm.
Btw, adding a module at boot always gives more pressure on the system, so that could also be the reason for more cpu usage.
To really compare better: do a remaster to use only one squashfs.
EDIT: Stupid me, just looked at it better: there are no kernel modules inside initrd3.xz, so nothing to load. Removed the link because it's useless.
Fred
Hi Toni, All,
For testing a new debdog-install:
- added syslinux and extlinux as options for choosing bootloader.
- fixed showing (sometimes) wrong label (showing from previous plugged in usb drive).
It will check filesystem type and then give the possible options to choose from a bootloader.
Included is: 'opt/apps/syslinux' folder which has the needed binaries and portable scripts 'syslinuxinst' and 'extlinuxinst' which are executed when the user choose extlinux or syslinux as bootloader.
The folder 'syslinux' will be copied to the install partition.
The scripts inside can also be used for manually install (execute from inside folder 'syslinux' on your flash drive}
As always, I'm open for any suggestions and wishes.
Just a little to large to attach here so here's link to gdrive:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
Fred
For testing a new debdog-install:
- added syslinux and extlinux as options for choosing bootloader.
- fixed showing (sometimes) wrong label (showing from previous plugged in usb drive).
It will check filesystem type and then give the possible options to choose from a bootloader.
Included is: 'opt/apps/syslinux' folder which has the needed binaries and portable scripts 'syslinuxinst' and 'extlinuxinst' which are executed when the user choose extlinux or syslinux as bootloader.
The folder 'syslinux' will be copied to the install partition.
The scripts inside can also be used for manually install (execute from inside folder 'syslinux' on your flash drive}
As always, I'm open for any suggestions and wishes.
Just a little to large to attach here so here's link to gdrive:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
Fred
Thank you, Fred!fredx181 wrote:For testing a new debdog-install:
I will test it proper tomorrow morning and write back.
William,
Just tested Dpup-Wheezy and it uses different gnome-mplayer 1.0.7 and it needs different dependencies than the one we use. To work on DebianDog gsettings-desktop-schemas package is needed for example and also few libs missing. I don't know if this affects the result.
BTW tested Dpup-Wheezy with 486 kernel module and live-boot-v2 and boots fine.
Toni
Thanks Toni. I have since booted both DpupWheezy and GuyDog via the DebianDog kernel method you suggested. In both cases their inbuilt mplayer was just as efficient (and pretty much equal to each other) as booting with their own kernel. So the kernel itself is not the culprit on my DebianDog installs... As I mentioned before, the Dec 2013 Porteus-Wheezy worked fine too. For that test I used apt-get to fetch the official Debian Mplayer and, as far as I recall, the cpu load was similar to that of GuyDog and DpupWheezy. I'll next try that mplayer version in DebianDog itself to see if that improves things on this relatively old machine of mine.
EDIT: One thing bothering my mind is that with DebianDog I always have to put vo=x11 in the mplayer config file in order to get video (though it won't fullscreen properly anyway), which suggests it won't work with xv on this old computer. But as far as I recall (I'll have to double check) the old Porteus-Wheezy, GuyDog and also DpupWheezy don't require me to do that and can all go fullscreen with mplayer. Yet, none of them shows as having mesa installed as far as hardinfo check suggested and none had Direct Render. I wonder if Xorg is different or they have some extra driver that works with xv even though they don't have mesa (I think)?
EDIT2: Ah, just remembered, mplayer also using too high cpu on my netbook, which doesn't need vo=x11 in mplayer config and can play videos fullscreen - that's what is really concerning me and why I want to get to the bottom of this. My old machine isn't so important if it was just a driver issue for that.
I'm still wondering if the main system components, for example Xorg, used in that Dec 2013 Porteus-Wheezy are the same as used in current DebianDog. Knowing that would help eliminate other suspects. Hoping you can provide the info for that one Fred!
It was certainly interesting being able to boot into DpupWheezy and later GuyDog via DebianDog vmlinux1 and initrd1.img and also using live-rw for persistent save file... Seemed to work fine! :-)
Fred: Good to hear about the deb install development with choice of grub4dos, syslinux, and extlinux etc. anikin will be happy I'm sure and perhaps the alternative method(s) will work where grub4dos doesn't.
EDIT: One thing bothering my mind is that with DebianDog I always have to put vo=x11 in the mplayer config file in order to get video (though it won't fullscreen properly anyway), which suggests it won't work with xv on this old computer. But as far as I recall (I'll have to double check) the old Porteus-Wheezy, GuyDog and also DpupWheezy don't require me to do that and can all go fullscreen with mplayer. Yet, none of them shows as having mesa installed as far as hardinfo check suggested and none had Direct Render. I wonder if Xorg is different or they have some extra driver that works with xv even though they don't have mesa (I think)?
EDIT2: Ah, just remembered, mplayer also using too high cpu on my netbook, which doesn't need vo=x11 in mplayer config and can play videos fullscreen - that's what is really concerning me and why I want to get to the bottom of this. My old machine isn't so important if it was just a driver issue for that.
I'm still wondering if the main system components, for example Xorg, used in that Dec 2013 Porteus-Wheezy are the same as used in current DebianDog. Knowing that would help eliminate other suspects. Hoping you can provide the info for that one Fred!
It was certainly interesting being able to boot into DpupWheezy and later GuyDog via DebianDog vmlinux1 and initrd1.img and also using live-rw for persistent save file... Seemed to work fine! :-)
Fred: Good to hear about the deb install development with choice of grub4dos, syslinux, and extlinux etc. anikin will be happy I'm sure and perhaps the alternative method(s) will work where grub4dos doesn't.
Last edited by mcewanw on Fri 02 May 2014, 09:19, edited 3 times in total.
github mcewanw
Hi, Fred!fredx181 wrote:For testing a new debdog-install:
- added syslinux and extlinux as options for choosing bootloader.
- fixed showing (sometimes) wrong label (showing from previous plugged in usb drive).
This new dobdog-install is great! Thank you!
I tested with syslinux and works fine on my both old hardware using plop boot floppy to get USB boot option. I will test it more today.
You also changed the default boot to live-boot-2 which is fine for me but maybe more people will use porteus-boot and we will change porteus as first boot option for next version.
I'm making instruction with pictures to post it in Utilities thread and I will post a message in DebianDog Beta thread. I hope more people will test this new installer if it works for any hardware.
Toni
Yes, it is amazing how well it works this way.mcewanw wrote:It was certainly interesting being able to boot into DpupWheezy and later GuyDog via DebianDog vmlinux1 and initrd1.img and also using live-rw for persistent save file... Seemed to work fine!
I hoped I can boot DebianDog with Puppy kernel and initrd.gz file from Dpup-Wheezy but it does not work so easy. It needs /etc/rc.d folder to be added in the main module and some other files. I managed to get it boot at last but X fails and it drops to command prompt with error message not finding display. Unfortunately reading the extracted puppy initrd files does not help me much to understand all I need to fix this. Still trying but I do not have big hopes for this. Even if it boots to X I think many other small issues will appear later.
Toni
Ah, very nice!Toni wrote:This new dobdog-install is great!
Can you wait a few hours with placing a link to it.
It was just for testing, I'd like to change some minor things like the text on the main window.
William, about Xorg on first Porteus-Wheezy, I didn't do anything special so I don't know why it could be different.
Good luck with your continuing search!
Fred
Sure, Fred.
I will wait for your next version. Then I will make new screenshots and a deb package with all needed files for grub4dos from the previous version. Installing the package will be all needed for using the new installer.
William,
Xorg is the same from the first version of Light-Wheezy till now. Nothing is removed or added (unless some later apt-get install program had some new Xorg dependency auto-installed).
Toni
I will wait for your next version. Then I will make new screenshots and a deb package with all needed files for grub4dos from the previous version. Installing the package will be all needed for using the new installer.
William,
Xorg is the same from the first version of Light-Wheezy till now. Nothing is removed or added (unless some later apt-get install program had some new Xorg dependency auto-installed).
Toni
Hi everyone,
I quickly ran dpupWheezy, just to have a look at its xorg log and compare it to DebianDog's log:mcewanw wrote:I'm still struggling away trying to get efficient mplayer performance on my old Pentium M laptop. Today I tried DpupWheezy to see what the result would be and to my surprise mplayer ran efficiently (three times less CPU than DebianDog on my system) - almost as good as GuyDog. And this apparently without mesa.
So then I checked with lsmod what modules were being loaded, and lo and behold, like GuyDog, it had agpgart and intel_agp and intel_gtt all available as modules under /lib/modules/kernel/drivers/char/agp
(I think that's where it was anyway - no longer running to check location). And all three of these were being auto-loaded on my machine at boot-time. On DebianDog, on the otherhand, there is no such directory of modulesm, instead they are listed as module.builtins for the kernel - that seems to be the key difference (and yes I do see agpgart when checking dmesg, but still mplayer runs rubbish on this machine unless they are loaded as modules, which I can't do with DebianDog).
Then, I backtracked, since I had a recollection the first Porteus-Wheezy, using Porteus kernel worked better on this machine. And sure enough, great mplayer performance on this machine again, and also agpgart.ko, intel_agp.ko and intel_gtt.ko all available and loaded automatically as modules. So that is what I need... But how do I get these modules for DebianDog or can I use that old Portues kernel/modules/firmware somehow on latest DebianDog - I think that would solve it for me?!Might well also solve similar issue for anyone else with a problem when that /lib/modules/kernel/drivers/char/agp directory doesn't exist on their system but instead all built into the official Debian kernel
DpupWheezy, at least uses software rasterization (DRISWRAST - circumcized mesa), whereas DebianDog has none =>dpupWheezy Xorg.0.log wrote:AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/i915_dri.so failed (/usr/lib/i386-linux-gnu/dri/i915_dri.so: cannot open shared object file: No such file or directory)
AIGLX: reverting to software rendering
AIGLX: Screen 0 is not DRI capable
AIGLX: Loaded and initialized swrast
GLX: Initialized DRISWRAST GL provider for screen 0
Can you install 'libgl1-mesa-dri' to check to see if it makes any difference? THe package isn't small - it's obscenely huge 80+MB! However, you only need 2 files: 'swrast_dri.so' for all cards and 'i915_dri.so' if the chip is Intel, or chose what's right for you from the list:DebianDog Xorg.0.log wrote:AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/i915_dri.so failed (/usr/lib/i386-linux-gnu/dri/i915_dri.so: cannot open shared object file: No such file or directory)
AIGLX: reverting to software rendering
AIGLX: Screen 0 is not DRI capable
AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/usr/lib/i386-linux-gnu/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
GLX: could not load software renderer
GLX: no usable GL providers found for screen 0
The issue is too important to not bring it to a sensible conclusion.File list of package libgl1-mesa-dri in wheezy of architecture i386
/etc/drirc
/usr/lib/i386-linux-gnu/dri/i915_dri.so
/usr/lib/i386-linux-gnu/dri/i965_dri.so
/usr/lib/i386-linux-gnu/dri/nouveau_dri.so
/usr/lib/i386-linux-gnu/dri/nouveau_vieux_dri.so
/usr/lib/i386-linux-gnu/dri/r200_dri.so
/usr/lib/i386-linux-gnu/dri/r300_dri.so
/usr/lib/i386-linux-gnu/dri/r600_dri.so
/usr/lib/i386-linux-gnu/dri/radeon_dri.so
/usr/lib/i386-linux-gnu/dri/swrast_dri.so
/usr/lib/i386-linux-gnu/dri/vmwgfx_dri.so
/usr/share/bug/libgl1-mesa-dri/control
/usr/share/bug/libgl1-mesa-dri/script
/usr/share/doc/libgl1-mesa-dri/changelog.Debian.gz
/usr/share/doc/libgl1-mesa-dri/copyright
/usr/share/lintian/overrides/libgl1-mesa-dri
Hi Toni
Here's new, probably final version of debdog-install.
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
It needed a major change:
When running gparted it went straight to the bootloader choice, fixed.
For the rest just some changes in information text.
And some changes in the scripts in syslinux directory and in syslinux/extlinux/extlinux.conf
Good idea to make deb package!
EDIT: Forgot to switch the order from live-boot v2 to porteus-boot as first.
If you want you can change maybe in syslinux/syslinux.cfg and syslinux/extlinux/extlinux.conf
Fred
Here's new, probably final version of debdog-install.
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
It needed a major change:
When running gparted it went straight to the bootloader choice, fixed.
For the rest just some changes in information text.
And some changes in the scripts in syslinux directory and in syslinux/extlinux/extlinux.conf
Good idea to make deb package!
EDIT: Forgot to switch the order from live-boot v2 to porteus-boot as first.
If you want you can change maybe in syslinux/syslinux.cfg and syslinux/extlinux/extlinux.conf
Fred
Hi anikin, thanks for that useful information. I've actually already tried libgl1-mesa-dri (the whole lot), though only on my older machine. Whilst some special mesa driver did appear when I then checked hardinfo report it had little if any effect on my mplayer cpu usage on this old machine. I had it in mind to try all that again on my other machine (an Atom powered netbook) but I haven't done that as yet. Good to know if I can get away with only these two files though.anikin wrote: Can you install 'libgl1-mesa-dri' to check to see if it makes any difference? THe package isn't small - it's obscenely huge 80+MB! However, you only need 2 files: 'swrast_dri.so' for all cards and 'i915_dri.so' if the chip is Intel, or chose what's right for you from the list:
...
The issue is too important to not bring it to a sensible conclusion.
However, as far as mplayer goes, at least as far as the excessive amount of cpu it uses on both my netbook and my older machine:
Alas, it seems to be the version of mplayer itself. I've swapped the DebianDog default version for the other one we tested Mplayer1.1 but the result was just as bad. However, when I instead used apt-get to install the official mplayer from debian the cpu used by mplayer was somewhere between one half and one third (I carefully removed all traces of the default version, including some symlinks to it I found in /usr/bin and /usr/local/bin, which I don't think with hindsight should be there - I actually deleted these symlinks because they seemed to be causing some strange side effects - correct mplayer not being found even though which mplayer revealed its correct location, and the cpu used by mplayer weirdly seemed to be effected too if I left the symlinks in!). All in all some very mysterious stuff going on with my machines at least (hope it's just mine) but really I'm doubting these two slitaz found mplayers now, which is a pity. The one in DpupWheezy runs well (in DpupWheezy) but it has tons of dependencies. Now I'm going to check Fred's openbox version of debiandog, just as a double check.
Really, I've been going round and round in circles for a few days now trying to get to the bottom of this. I have several clean installs prepared just to avoid any trouble.
github mcewanw
Anikin, Just looking at the above leads me to wonder, what is it that is in DpupWheezy that provides DRISWRAST, is that swrast_dri.so? And when you suggest also i915_dri.so for chip Intel, is that to provide hardware-based direct rendering rather than software renderer? I imagine at least software renderer (no matter what graphics chip is used in the system) would be useful in default iso if my understanding of your comments is correct.anikin wrote:DpupWheezy, at least uses software rasterization (DRISWRAST - circumcized mesa), whereas DebianDog has none =>GLX: Initialized DRISWRAST GL provider for screen 0DebianDog Xorg.0.log wrote:AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/i915_dri.so failed (/usr/lib/i386-linux-gnu/dri/i915_dri.so: cannot open shared object file: No such file or directory)
AIGLX: reverting to software rendering
AIGLX: Screen 0 is not DRI capable
AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/usr/lib/i386-linux-gnu/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
GLX: could not load software renderer
GLX: no usable GL providers found for screen 0
I've noticed there might also be this:
http://mentors.debian.net/package/mesa-legacy
libgl1-mesa-dri-legacy, which may or may not be relevant for my older computer.
github mcewanw
Oddly, I've just tried DebianDog openbox version and mplayer seems to consume only half the CPU as it does on DebianDog jwm, but I could be wrong and hope some of you other guys can test that.
EDIT: That seems to have been another mysterious fluke. On a second run the CPU load for mplayer on this machine is just as high as on jwm version of DebianDog. So far I therefore stand by my feeling that there is something not good about these two mplayers, at least for DebianDog (the svn version and the 1.1 version, both from slitaz originally). But so many weird results I need someone else to check against other distribution's mplayer and against official (big) Debian mplayer. On this old machine of mine top suggests that mplayer is consuming almost 40% cpu running video in small window, which is roughly twice as much as when I tested with official Debian mplayer on clean system. Actually, on the openbox version the result seems to be intermittent (sometimes ok, sometimes not - hope others can test in case just my machines). Also, compare against DpupWheezy running same video if you can.
This is on my old Pentium M 1.6GHz, I GB ram machine, so maybe your results will be different. I do note that no direct rendering or software rendering on this one either. Hopefully we can include swrast_dri.so by default without needing full mesa installed?:
Xorg.0.log extract:
EDIT: That seems to have been another mysterious fluke. On a second run the CPU load for mplayer on this machine is just as high as on jwm version of DebianDog. So far I therefore stand by my feeling that there is something not good about these two mplayers, at least for DebianDog (the svn version and the 1.1 version, both from slitaz originally). But so many weird results I need someone else to check against other distribution's mplayer and against official (big) Debian mplayer. On this old machine of mine top suggests that mplayer is consuming almost 40% cpu running video in small window, which is roughly twice as much as when I tested with official Debian mplayer on clean system. Actually, on the openbox version the result seems to be intermittent (sometimes ok, sometimes not - hope others can test in case just my machines). Also, compare against DpupWheezy running same video if you can.
This is on my old Pentium M 1.6GHz, I GB ram machine, so maybe your results will be different. I do note that no direct rendering or software rendering on this one either. Hopefully we can include swrast_dri.so by default without needing full mesa installed?:
Xorg.0.log extract:
Code: Select all
[ 37.829] (EE) AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/r300_dri.so failed (/usr/lib/i386-linux-gnu/dri/r300_dri.so: cannot open shared object file: No such file or directory)
[ 37.829] (EE) AIGLX: reverting to software rendering
[ 37.829] (II) AIGLX: Screen 0 is not DRI capable
[ 37.829] (EE) AIGLX error: dlopen of /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/usr/lib/i386-linux-gnu/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
[ 37.829] (EE) GLX: could not load software renderer
[ 37.829] (II) GLX: no usable GL providers found for screen 0github mcewanw
Yes, that's how I understand it.mcewanw wrote:what is it that is in DpupWheezy that provides DRISWRAST, is that swrast_dri.so? And when you suggest also i915_dri.so for chip Intel, is that to provide hardware-based direct rendering rather than software renderer? I imagine at least software renderer (no matter what graphics chip is used in the system) would be useful in default iso if my understanding of your comments is correct
Mesa = swrast_dri.so (common for all chips)
+
i915_dri.so/i965_dri.so/nouveau_dri.so/nouveau_vieux_dri.so/r200_dri.so/r300_dri.so/r600_dri.so/radeon_dri.so
There must have been a good reason, why pemasu put the common part into his dpup. He's very particular about this stuff.
Hi, Fred.
Added here and in the first post:
http://murga-linux.com/puppy/viewtopic. ... 949#774949
But if we leave porteus-boot default and someone decide to make full remaster with RemasterDog (which is possible with 2 Gb RAM) this will include 021-apps-porteus in the main module. Then with live-boot-2/3 it will start porteus make save file changes.dat for every boot and porteus loadmodule.
I think live-boot-v2 is the best default boot for any case.
Toni
Added here and in the first post:
http://murga-linux.com/puppy/viewtopic. ... 949#774949
I left live-boot-2 as default. I changed grub4dos the same way in the deb package. The reason to change default boot from live-boot-3 was RemasterCow does not work there and it can not be used from first boot without save file.fredx181 wrote:EDIT: Forgot to switch the order from live-boot v2 to porteus-boot as first.
But if we leave porteus-boot default and someone decide to make full remaster with RemasterDog (which is possible with 2 Gb RAM) this will include 021-apps-porteus in the main module. Then with live-boot-2/3 it will start porteus make save file changes.dat for every boot and porteus loadmodule.
I think live-boot-v2 is the best default boot for any case.
Toni
Hi Toni,
live-boot v2 is fine by me as default but still the problem persists if a user makes remaster using porteus-boot, right?
I did already with some scripts a check if a typical porteus-boot file exists (in /mnt/live/..) and if not uses /live/cow instead of /mnt/live/memory/changes.
For example new apt2sfs does that.
I'll look at it, maybe it's even possible not needing 021-apps-porteus at all.
Nice pictures for the installer in the utilities thread!
Fred
Yes, I see what you mean.But if we leave porteus-boot default and someone decide to make full remaster with RemasterDog (which is possible with 2 Gb RAM) this will include 021-apps-porteus in the main module. Then with live-boot-2/3 it will start porteus make save file changes.dat for every boot and porteus loadmodule.
I think live-boot-v2 is the best default boot for any case.
live-boot v2 is fine by me as default but still the problem persists if a user makes remaster using porteus-boot, right?
I did already with some scripts a check if a typical porteus-boot file exists (in /mnt/live/..) and if not uses /live/cow instead of /mnt/live/memory/changes.
For example new apt2sfs does that.
I'll look at it, maybe it's even possible not needing 021-apps-porteus at all.
Nice pictures for the installer in the utilities thread!
Fred
Hi, Fred.
http://murga-linux.com/puppy/viewtopic. ... 212#773212
Most of the programs using /live/cow and /live/image are universal for porteus-boot and live-boot-2. We have symlinks in 021-apps-porteus for /live/cow and /live/image
My opinion is not to change something that works. Also for my personal use I prefer the default shutdown menu and keeping obshutdown only for porteus boot, but if you like to work on excluding porteus module we will install obshutdown.
Toni
This information is already included in RemasterDog post:fredx181 wrote:live-boot v2 is fine by me as default but still the problem persists if a user makes remaster using porteus-boot, right?
http://murga-linux.com/puppy/viewtopic. ... 212#773212
Most of the programs using /live/cow and /live/image are universal for porteus-boot and live-boot-2. We have symlinks in 021-apps-porteus for /live/cow and /live/image
My opinion is not to change something that works. Also for my personal use I prefer the default shutdown menu and keeping obshutdown only for porteus boot, but if you like to work on excluding porteus module we will install obshutdown.
Toni
Hi, William.
Testing machine IBM Netvista PIII-600Mhz, 128 Mb RAM, 2Gb SWAP. Playing the same video file after first boot fresh install without save file for DebianDog-jwm and DpupWheezy:
DebianDog gmplayer = 44% CPU
DebianDog using xhippo = 34% CPU
Dpup-Wheezy gmplayer = 31% CPU
Xorg log for debianDog:
http://smokey01.com/saintless/Fredx181/ ... Xorg.0.log
Xorg log for Dpup-Wheezy:
http://smokey01.com/saintless/Fredx181/ ... Xorg.0.log
Just to add this CPU usage result means nothing to me, William. It may look funny I use such old hardware for DebianDog, but there is a good reason and it gives the results I want. This video is playing real nice on this machine with DebianDog xhippo and gmplayer. Even Turbopup can't play it so nice.
Toni
I can't find anything mplayer related in /usr/bin. Can you point what links you have there? I guess your problem after apt-get mplayer comes from /opt/bin/mplayer links since /opt/bin is first in PATHmcewanw wrote:... (I carefully removed all traces of the default version, including some symlinks to it I found in /usr/bin and /usr/local/bin, which I don't think with hindsight should be there - I actually deleted these symlinks...
Testing machine IBM Netvista PIII-600Mhz, 128 Mb RAM, 2Gb SWAP. Playing the same video file after first boot fresh install without save file for DebianDog-jwm and DpupWheezy:
DebianDog gmplayer = 44% CPU
DebianDog using xhippo = 34% CPU
Dpup-Wheezy gmplayer = 31% CPU
Xorg log for debianDog:
http://smokey01.com/saintless/Fredx181/ ... Xorg.0.log
Xorg log for Dpup-Wheezy:
http://smokey01.com/saintless/Fredx181/ ... Xorg.0.log
Just to add this CPU usage result means nothing to me, William. It may look funny I use such old hardware for DebianDog, but there is a good reason and it gives the results I want. This video is playing real nice on this machine with DebianDog xhippo and gmplayer. Even Turbopup can't play it so nice.
Toni