Lucid Puppy 5.2.8 - Updated ISO Version 005 - APR 05 2012
did fresh frugal instal lupu plus to same hp laptop.
wl recognized eth1 by sns but not able to make the connection.
connection wizard easily made connection on this troublesome
Broadcom Corporation BCM4313.
This is the opposite of yesterdays install lupulibre where
connection wizard failed and sns made the connection.
seems odd and cannot remember how prior install of lupu plus
went so attached file.
wl recognized eth1 by sns but not able to make the connection.
connection wizard easily made connection on this troublesome
Broadcom Corporation BCM4313.
This is the opposite of yesterdays install lupulibre where
connection wizard failed and sns made the connection.
seems odd and cannot remember how prior install of lupu plus
went so attached file.
http://www.murga-linux.com/puppy/viewto ... 372#619372About Stellarium: the SFS behaves identical to the 1.10.6 pet. It brings up the stellatium logo, then crashes X to terminal. You can type reboot to restart the PC. Please find attached stellarium log file. It seems it destroys QProcess ... does that ring a bell ?
great LibreOffice integration with the Desktop
This is an FYI!
"And, I noticed a phenomenon that I find interesting, at best. Playdayz's PUP528R5's LibreOffice version is a performance Superstar as compared with taking his base version and adding LibreOffice SFS or PET to it. In fact, it rivals TaZoC implementaion.
Wish I could explain why the integration has leapfroged a performance increase."
Hope this helps
"And, I noticed a phenomenon that I find interesting, at best. Playdayz's PUP528R5's LibreOffice version is a performance Superstar as compared with taking his base version and adding LibreOffice SFS or PET to it. In fact, it rivals TaZoC implementaion.
Wish I could explain why the integration has leapfroged a performance increase."
Hope this helps
Libre Office is running from ram. Also --nologo makes it startup slightly faster, or at least seem to. Make sure to use the doc-type-LibO-set-1.pet for best integration.Wish I could explain why the integration has leapfroged a performance increase."
-------------------------------------------------------------------------------------------------
TEASER
Don't know what will come of it, but it boots and connects, and reboots and creates and uses a pupsave.
- Attachments
-
- teaser.png
- (19.46 KiB) Downloaded 1011 times
- Iguleder
- Posts: 2026
- Joined: Tue 11 Aug 2009, 09:36
- Location: Israel, somewhere in the beautiful desert
- Contact:
My advice to you, playdayz: make a x86_64 flavor of this kernel.
This has five benefits:
- Access to 4 GB (or more) RAM, without the PAE issues (e.g instability under certain circumstances).
- The ability to run x86_64 binaries (e.g compile x86_64 stuff from a chroot environment).
- The performance boost of 64-bit computing - e.g some heavy computations (such as compression) implemented in kernel mode are now faster.
- Same userland - no need to recompile anything or create a separate package repository, as with i486/i686 switching.
- Dual-kernel ISOs with two identical kernels - one for 64-bit machines and another for 32-bit ones - it's quite cool.
This has five benefits:
- Access to 4 GB (or more) RAM, without the PAE issues (e.g instability under certain circumstances).
- The ability to run x86_64 binaries (e.g compile x86_64 stuff from a chroot environment).
- The performance boost of 64-bit computing - e.g some heavy computations (such as compression) implemented in kernel mode are now faster.
- Same userland - no need to recompile anything or create a separate package repository, as with i486/i686 switching.
- Dual-kernel ISOs with two identical kernels - one for 64-bit machines and another for 32-bit ones - it's quite cool.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
@Playdayz you shared
Anyway, looking forward .....
______________________________________
There is one issue that I hope my statement clarifies. PAE doesn't have any more of an instability issue than "normal" or the "4GB only" 32bit kernels present. It, like the others 32bit mentioned, is stable.
The PROBLEM with PAE is that there are a very few CPUs manufactured by Intel and others which (for their cost considerations) did NOT include the PAE hardware. And, some BIOSes were also shipped with a settings that could also have impacted PAE use. But, for the most part, this is a ratity given the 15 years PAE has been built-into CPUs.
Thus, if you can, run 64bit! If you cannot, use 32bit PAE as it affords use of ALL of the RAM you can throw at it (assuming no CPU issues - which you will find out almost immediately), Lastly 32bit non-PAE runs just as fast (reviewing performance measurements already done by both vendors (intel and AMD) as well as independent test reports. PAE merely shines in Puppy which run RAM based because the filesystem is ALL of your RAM.
Hope this helps
Is this a "pre-announcment"? or a reference to someone else's work (i'e' Pemasu)?TEASER
Anyway, looking forward .....
______________________________________
@Iguleder shares these great Benefits. LightHouse64 has demonstrated these.Iguleder wrote:My advice to you, playdayz: make a x86_64 flavor of this kernel.
This has five benefits:
- Access to 4 GB (or more) RAM, without the PAE issues (e.g instability under certain circumstances).
- The ability to run x86_64 binaries (e.g compile x86_64 stuff from a chroot environment).
- The performance boost of 64-bit computing - e.g some heavy computations (such as compression) implemented in kernel mode are now faster.
- Same userland - no need to recompile anything or create a separate package repository, as with i486/i686 switching.
- Dual-kernel ISOs with two identical kernels - one for 64-bit machines and another for 32-bit ones - it's quite cool.
There is one issue that I hope my statement clarifies. PAE doesn't have any more of an instability issue than "normal" or the "4GB only" 32bit kernels present. It, like the others 32bit mentioned, is stable.
The PROBLEM with PAE is that there are a very few CPUs manufactured by Intel and others which (for their cost considerations) did NOT include the PAE hardware. And, some BIOSes were also shipped with a settings that could also have impacted PAE use. But, for the most part, this is a ratity given the 15 years PAE has been built-into CPUs.
Thus, if you can, run 64bit! If you cannot, use 32bit PAE as it affords use of ALL of the RAM you can throw at it (assuming no CPU issues - which you will find out almost immediately), Lastly 32bit non-PAE runs just as fast (reviewing performance measurements already done by both vendors (intel and AMD) as well as independent test reports. PAE merely shines in Puppy which run RAM based because the filesystem is ALL of your RAM.
Hope this helps
I don't think so. Sometimes PPM misses dependencies that are really there. If it works it's OK. There is also a 1.1.10. This vlc 2.0 is for me working in quick testing -> http://www.murga-linux.com/puppy/viewtopic.php?t=76271Downloaded vlc-1.1.7.-full-lucid52 from PPM.
It seems to work OK, but did get this message after the install check.
Problem?
jim3630 wrote:did fresh frugal instal lupu plus to same hp laptop.
wl recognized eth1 by sns but not able to make the connection.
connection wizard easily made connection on this troublesome
Broadcom Corporation BCM4313.
This is the opposite of yesterdays install lupulibre where
connection wizard failed and sns made the connection.
seems odd and cannot remember how prior install of lupu plus
went so attached file.
- 1. Lupuplus has the older wl driver which uses eth1 and gives you trouble.
2. With lupulibre, you installed the 2 packages that add support for both the old and a newer version of the wl driver (which appears to successfully support your device), but did not do that when you ran lupuplus.
Richard
Last edited by rerwin on Thu 12 Apr 2012, 22:42, edited 1 time in total.
The intel driver did not fix it. I am going to read through Pesamu's advice first. But I am not sure if the problems I have relate to his work on Qt. Since it works on other hardware on LupuLibre, on Nvidia HW, Qt should not be the problem.playdayz wrote:volhut, it would be a miracle if this updated Intel video driver for Lucid from Ubuntu Lucid Updates made any difference to Stellarium. You would need to restart the X-server after installing the pet.
UPDATE: when I use Xvesa on 1024x768x24 the Stellarium 1.10.6 SFS works on my system. It is slow (graphics), but it works. Using Xorg on the same settings 1024x768x24 does not work, neither does the native setting for my system 1280x1024x24.
I did not know Xvesa supported OpenGL (via Xorg-High ?)
playdayz wrote:TEASER
Don't know what will come of it, but it boots and connects, and reboots and creates and uses a pupsave.
Might as well give it a try, but I agree with Iguleder that x86_64 is the way of the future.
It's most certainly possible and appears to work pretty darn well.Iguleder wrote:My advice to you, playdayz: make a x86_64 flavor of this kernel.
- Attachments
-
- Precise Puppy k-3.10 x86_64.png
- (27.41 KiB) Downloaded 1072 times
Volhout
I had a box with brookdale 845G video which gave all sorts of problems
I think I cured it by adding mesa and going into bios and resetting the default video memory size to match the video...I got good speed and stability afterwards - though I also came across a lot of 'this patch isn't working' posts when searching....there were kernel problems too, apparently, so look for patches for your kernel
Aitch
I had a box with brookdale 845G video which gave all sorts of problems
I think I cured it by adding mesa and going into bios and resetting the default video memory size to match the video...I got good speed and stability afterwards - though I also came across a lot of 'this patch isn't working' posts when searching....there were kernel problems too, apparently, so look for patches for your kernel
Aitch
I agree also, James C. But it won't be me who does it I am using the kernel from racy 5.3. One thing I am interested in is whether it makes a difference whether a kernel is built-in with Woof or added later manually. I am building it in with Woof.I agree with Iguleder that x86_64 is the way of the future.
Got a feeling it'll go much smoother using Woof....playdayz wrote: One thing I am interested in is whether it makes a difference whether a kernel is built-in with Woof or added later manually. I am building it in with Woof.
Anyway, it'll give us a new release to experiment with.Might as well go for it.
Playdayz,playdayz wrote:I agree also, James C. But it won't be me who does it I am using the kernel from racy 5.3. One thing I am interested in is whether it makes a difference whether a kernel is built-in with Woof or added later manually. I am building it in with Woof.I agree with Iguleder that x86_64 is the way of the future.
Do not do it! In no way should you proceed! You have better things to do! What are you wasting your time for! Total wast! Who needs it! Who wants it! What are you thinking!
GOT YOU FIRED UP TO DO IT?
I HOPE SO!!!!!!!!!
PLEASE! PLEASE! PLEASE! PLEASE!
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
1+bigpup wrote:Playdayz,playdayz wrote:I agree also, James C. But it won't be me who does it I am using the kernel from racy 5.3. One thing I am interested in is whether it makes a difference whether a kernel is built-in with Woof or added later manually. I am building it in with Woof.I agree with Iguleder that x86_64 is the way of the future.
Do not do it! In no way should you proceed! You have better things to do! What are you wasting your time for! Total wast! Who needs it! Who wants it! What are you thinking!
GOT YOU FIRED UP TO DO IT?
I HOPE SO!!!!!!!!!
PLEASE! PLEASE! PLEASE! PLEASE!
If I run VLC 1.1.7 from the console. I also get these error messages:playdayz wrote:I don't think so. Sometimes PPM misses dependencies that are really there. If it works it's OK. There is also a 1.1.10. This vlc 2.0 is for me working in quick testing -> http://www.murga-linux.com/puppy/viewtopic.php?t=76271Downloaded vlc-1.1.7.-full-lucid52 from PPM.
It seems to work OK, but did get this message after the install check.
Problem?
# vlc
VLC media player 1.1.7 The Luggage (revision exported)
Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS")
Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE")
[0x8103834] main interface error: no suitable interface module
[0x8067564] main libvlc error: interface "globalhotkeys,none" initialization failed
[0x8067564] main libvlc: Pokretanje VLC-a s polaznim su
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
There is this warning in the topic for VLC 2.0.0.sfs:
Is this something to worry about if using in Lucid 5.2.8-005?EDIT: the vlc sfs also works in the new Slacko beta but if are using
qt-473 in slacko the qt-480 in the vlc sfs will clobber it and the
programs in slacko that used qt-473 won't work any longer.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Not really. Lucid does not have a separate Qt package like Slacko does.EDIT: the vlc sfs also works in the new Slacko beta but if are using
qt-473 in slacko the qt-480 in the vlc sfs will clobber it and the
programs in slacko that used qt-473 won't work any longer.
Is this something to worry about if using in Lucid 5.2.8-005?