Fatdog64-700 beta1

[kirk]

Quote:
The chrome version of Opera has been released for linux, so far only as a 64-bit deb http://www.opera.com/computer/beta. As I posted here, in Fatdog 700, every release but one of opera-developer and opera-beta doesn't render fonts in the user interface, although web pages are ok. (The one exception is opera-developer-25.0.1613.1; it apparently works perfectly in Fatdog and Neeraj has made an sfs of it.) I reported this as a bug to Opera, and received the following reply:


Yes, that's a problem and so far not an easy one to fix. This will keep me busy.

Oh boy, did that keep me busy. Anyway it's fixed for beta2. I tested with Google-Chrome which seemed to have the same problem.

[LateAdopter]

Hello jamesbond and kirk

While I was experimenting with VDPAU, Leo Liu of AMD started posting some patches to reinstate the Radeon vaapi state tracker and it's now in mesa master.

I cheated and repackaged Fabio's latest Trusty Ubuntu packages from launchpad for fatdog. He knows what he's doing with this experimental stuff and it works at first sight:

Code: Select all

# LIBVA_DRIVER_NAME=gallium vainfo
libva info: VA-API version 0.36.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'gallium'
libva info: Trying to open /usr/lib64/dri/gallium_drv_video.so
libva info: Found init function __vaDriverInit_0_35
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.36 (libva 1.4.0.pre1)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileH264Baseline           :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointVLD

It needs the LIBVA_DRIVER_NAME variable in order to find the driver. Could you tell me where I should put it in fatdog, in order to set it permanently?

Then I'll test to see if it actually does anything...

Thanks

EDIT I remembered from earlier /etc/profile

[-MoMo-]

@jamesbond
Your info is really very enlightening.

[-MoMo-]

...

[step]

@step - thank you for your contribution. I haven't tried building R, from a quick search it seems that there is in fact a bug in gfortran ... I'll look into this later when I have more time.

Thanks. Meanwhile this is what I'm doing. I have assumed that it's a FD gfortran bug. I downloaded a gfortran 4.9.2 binary snapshot from gfortran.com and (after some cajoling) I was able to compile R into a working package. Hurray. But before I upload the R package I want to find a permanent fix for gfortran on FD. R needs a working fortran compiler to be really useful, because it loads language extensions by compiling them from source. Most extensions are written in c/cpp but there are many recommended extensions written in fortran. So a working gfortran is almost mandatory.
So I embarked into building GCC 4.9.2 (experimental) myself but I'm stuck on an issue, whereby libcpp.a and libdecnumber.a don't get built - as the Makefile includes no rules for them at all - and yet target cc1-checksum requires both of them. Have you seen something like this before? I don't know what target cc1-checksum is for, it's part of the GCC architecture then what?
Anyway, to try and get past this new issue my plan is to downgrade source code to version 4.9.1 (stable) and try building it with languages=c,c++,fortran only. If that works I could make an alternative set of compilers in /usr/local to replace the set in devx.sfs when my R package is loaded.

edit 1: version 4.9.1 builds just fine: gcc-4.9.1 gmp-4.3.2 mpfr-2.4.2 mpc-0.8.1

Code: Select all

Target: x86_64-fatdog-linux-gnu
Configured with: ../gcc-4.9.1/configure --with-stage1-ldflags=-static-libgcc --with-boot-ldflags=-static-libgcc --prefix=/usr/local --libdir=/usr/local/lib64 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --with-system-zlib --enable-lto --enable-languages=fortran --disable-bootstrap --build=x86_64-fatdog-linux-gnu --enable-checking=release --disable-libmudflap
Thread model: posix
gcc version 4.9.1 (GCC) 

make check: 1 of 58 tests failed
make[6]: Leaving directory '/root/build/gmp/tests/mpz'
Makefile:1104: recipe for target 'check-am' failed

Next step: build again with more recent infrastructure modules.

edit 2: gcc-4.9.1 gmp-5.1.3 mpc-1.0.2 mpfr-3.1.2
The above combination yields better test results. Versions of infrastructure modules match the versions in FD 700 devx.sfs. I also tested gmp-6.0.0a and had a few more failed tests. I haven't got the time to investigate test failures. For this run:

Code: Select all

SKIP 4
PASS 1506
FAIL 64
1574 tests (over 56 categories or less).

Next step: build R again with this new compiler.

edit 3: Yes! R did compile fine with this new gcc+gfortran compiler mixed with the gcc in the devx SFS.[/i

edit 4: Checked R, OK. Checked gfortran OK. They work together seemengly well. I have packaged them as two separate txz files.

edit 5: Package download: http://murga-linux.com/puppy/viewtopic. ... 845#801845

[Wognath]

@jamesbond

RE:opera - actually, isn't better if that opera dev himself download Fatdog and test opera there? It being closed source doesn't help ...

Opera people are helpful, but apparently not that helpful! Re palemoon, there's even a thread about using it to replace opera. http://murga-linux.com/puppy/viewtopic.php?t=92976 I tried it briefly and may try again. And thanks for the link to revised txz package instructions. It's very comprehensive.
@kirk

Oh boy, did that keep me busy. Anyway [opera] is fixed for beta2.

Wow! Thanks! Can the problem be explained in a way I might understand? Since I fooled with this a lot, I'm curious.
@Q5sys

If I were you I'd try out Otter Browser. it's an open source implementation of the 12.x series or Opera

Thanks for this suggestion, I will try it. Opera 12.16 is beginning to cause problems, so I'm trying to move on even though I'm not sure I can live without mail client (I'm trying to learn to love Sylpheed) and password key.

[TJK]

As for savefile: Fatdog by default only try to load "fdsave64.*" from root partition. If you change the name, or put in a subdirectory, you *must* use savefile option to find it. There is a utility in Control Panel that can help you to build the correct "savefile=" parameter.

For fatdog installer woes - did you tick the option "small-initrd"? If you do, it will re-create the SFS and that could take a long time. Also, you can run the installer from terminal "fatdog-installer.sh" and there may be some diagnostic output ...

As for init.cfg, I have no idea what it is ... what bootloader do you use?

Thanks for you help JamesBond:

I tried your suggestions for installing FD on my USB3 SSD, and I tried several of the bootloaders (first three options). Some times it would install the bootloader, but for some reason the installer would hang right at the end -- it said something about reading the disk... although I could read and write to the usb drive, the installer had problems finalizing the instalation. What I eventually did was use unetboot to complete the install. (When running unetboot I justselected the options to NOT overwrite the files and leave them as FD installer had done). Whatever unetboot did to make the usb bootable, I don't know... but FD installer couldn't do what unetboot did, as FD boots, saves, etc now. And I don't have the mouse acceleration issues that I had before.

When I discovered the savefile config script, it gave me all the info (including the UUID) that I needed to config the init for running FD with my SSD. Very helpful tool.

So now I'm using the sandbox to see how my newly configured python apps will work with FD... hopefully better then all the Puppy versions that I tried...

One last question-comment. I've found that a couple apps are not showing up in the menu (like gparted), and it appears that there are a LOT more run scripts in /usr/bin then what are in the menu. I've rerun-rescanned the menu, but it makes no difference.

[Q5sys]

@Q5sys - I'm surprised that Opera open-sourced their 12.x browser. I thought they would have kept it as a trade secret. Is this is a real Opera-based source, or is this is a re-implementation that tries to emulate what Opera 12.x has?

No Opera has not released their source.
It's a re-implementation intended of emulating the 12.x series which was without a doubt the best Opera Browser before they went with the webkit base. I've used it on Windows and on Arch and I really like it. It's not quite on par with the older Opera, but considering the project has only been around for less than a year (I think)... what they have so far is very impressive.

Not all of Opera was closed source, only parts, so that's really the part that needs to be redesigned. The rest is probably pulled from the older Opera Code which is open source.

Couple of other questions for you while I get used to the fatdog way of doing things.

1) Previously in openbox Im used to, with respect to the desktop, left click being the application menu and right click being task process list. In fatdog left click is nothing and right is the application menu.

Where are these settings saved? I'd kinda like to revert mine to what Im used to. But I've never bothered to look to see where this is.

2) Another config question so I can edit my system. This actually was a question from my sister, and I dont know how to implement it for her. When you right click on a drive icon on the desktop you get the following. What do I have to edit so that I can add a 'Open in Gparted' option for her?



@ All

Has anyone built gkrellm yet? If not I'll build it this week.

[kirk]

1) Previously in openbox Im used to, with respect to the desktop, left click being the application menu and right click being task process list. In fatdog left click is nothing and right is the application menu.

You'll want to look at /etc/xdg/openbox/rc.xml. Around line 550 is where the right click action is defined.

2) Another config question so I can edit my system. This actually was a question from my sister, and I dont know how to implement it for her. When you right click on a drive icon on the desktop you get the following. What do I have to edit so that I can add a 'Open in Gparted' option for her?

Not real easy. You'd have to edit some of the /usr/sbin/fatdog-drive-icon-* scripts.

One last question-comment. I've found that a couple apps are not showing up in the menu (like gparted), and it appears that there are a LOT more run scripts in /usr/bin then what are in the menu. I've rerun-rescanned the menu, but it makes no difference.

Many have been moved to the Control Panel. Gparted is in the Control Panel under the Utilities tab.

[jamesbond]

@Q5sys -

2) Another config question so I can edit my system. This actually was a question from my sister, and I dont know how to implement it for her. When you right click on a drive icon on the desktop you get the following. What do I have to edit so that I can add a 'Open in Gparted' option for her?

Not real easy. You'd have to edit some of the /usr/sbin/fatdog-drive-icon-* scripts.

Look at /usr/sbin/fatdog-drive-icons-roxlib.sh.

@step - that's great progress. Thank you for your continuing effort.

@LateAdopter - thanks for testing. Assuming you tried, this, is there any visible performance benefit? (lower cpu usage, lower cpu temp, better image quality, etc)? If the patches are already in mesa master branch hopefully by next release it will go in.

@Wognaht -

Wow! Thanks! Can the problem be explained in a way I might understand? Since I fooled with this a lot, I'm curious.

I was being an idiot I used the latest and greatest of fontconfig from git master, and didn't realise that it broke compatibility to *ALL* previous versions. Applications compiled in Fatdog will work fine, but foreign applications compiled with older fontconfig will fail in mysterious ways - chrome included. Thanks kirk for cleaning this one up for me

[LateAdopter]

Hello jamesbond

@LateAdopter - thanks for testing. Assuming you tried, this, is there any visible performance benefit? (lower cpu usage, lower cpu temp, better image quality, etc)? If the patches are already in mesa master branch hopefully by next release it will go in.

Progress so far:

VDPAU nearly works in VLC. It displays proper pictures but at a jerky playback speed. VLC doesn't show any errors/warnings/debug about it. I suppose the problem is between ffmpeg and VDPAU. i wonder how old the version of ffmpeg in VLC 2.1 is, since VLC 2.2 has been WiP for a long time.

I tried VAAPI but neither VLC nor the MPlayer-static from the repo seem to do it.

I'm going to try a Trusty version of MPV 0.6.0 from launchpad. The MPV fork of MPlayer is what the experts use, and has VDPAU and VAAPI by default. It's a single binary but there are 16 dependencies to get.

My hardware: AthlonII x2 240, can do 1080i50 H.264 + YADIF 2x deinterlace in software on fatdog64 at about 60% cpu load and 52Watts wallplug power.

Without deinterlace it's about 45W. (Idle is 36W in fatdog, 27W in win2k)

With VDPAU it was 42W without deinterlace. But my theory is that, once VDPAU or VAAPI is working, motion adaptive deinterlace should not increase the power.

The patches to enable UVD on my RS880G are quite new and the Radeon VAAPI stuff is only days old, so I'm sure there are bugs to fix.

The kernel UVD patches are not officially until 3.18 but they worked with 3.16.2
The mesa UVD patches are in 10.3 and Radeon VAAPI is in 10.4.

It's only an experiment, since Fatdog can do the job quite well on its own. Thanks for your work on it.

[GKM]

Hi there,

Is there a package for fatdog which helps out with (USB) power management somewhere?

The problem I need to resolve has to do with the power management of USB ports. I have a usb peripheral device which interfaces smoothly with fatdog when attached to a desktop PC, but the identical Fatdog system transferred to a notebook initially transfers data to and from the device, but after some time fails to communicate with that device. Tests of the USB ports did not reveal any issues, and Fatdog loads just fine using any of the USB ports.

As the failure is only after some time, and because Fatdog boots up with the screen backlight at minimum setting, even using AC power, this led me to believe the USB power management has something to do with it. I checked the BIOS, but changing the USB power settings there makes no difference.

Is there any way in Fatdog to make sure the USB ports never suspend?

Thanks in advance.

Regards,

GKM.

[jamesbond]

@LateAdopter - thank you for explanation.

@GKM -

Is there any way in Fatdog to make sure the USB ports never suspend?

Yes, it's possible. You just need to do echo "on" > /sys/bus/usb/xxxxxx/power/control but you need to know where is the "xxxxx" (it represents the system path to your USB device/port). All that is needed is to write a script to map between your usb device/port and that system path.

[step]

I have uploaded two new packages built on and for FD64 700:

• R Project For Statistical Computing
• gcc+gfortran 4.9.1 - merely in support of R

Download and notes: http://murga-linux.com/puppy/viewtopic. ... 845#801845
Forum thread: http://murga-linux.com/puppy/viewtopic. ... 673#802673

[TJK]

I was trying to install e17 and I messed up (corrupted) my fatdog64 700b2 instalation. Since I'm still very new to this distro, I didn't realize that you don't, by default, have multisessions... so, it appears that I can't recover my previous session. Is this correct?

And if the above senario is not possible, would there be a way that I can restore the base system? (I would prefer not to install FD again.) I tried booting without savefile, but when I exit FD, it only lets me save to CD (this seems odd) -- and I want it to overwrite the savefile on my USB SSD.

UPDATE: I tried a few things... I started in savefile=none mode, then I renamed the savefile I was using, then I opened init.cfg and changed the custom line for my default savefile to a new named savefile (fd64save2.ext4). Then I rebooted, and while shutting down created a new hostname, password and savefile (fd64save2.ext4). BUT when the system started (using fd64sve2), FD stalled with errors showing in the xorg.cfg file. I started xorgwizard, but all options including the vesa driver failed to work. It appears that something other then the savefile is the problem...

[GKM]

Hi jamesbond,

Thanks for the swift response. I managed to change a few power/control files this way. Sadly though, it did not resolve my problem. This may be due to a hardware fault somewhere, or it could be that this notebook is on a docking station with some usb hubs, and it might be that I have been unable to find the right control file.

Entertaining the, perhaps idle, hope that it is not a hardware fault in the notebook or peripheral, I searched the web. I read that adding usbcore.autosuspend=-1 to the kernel line would make sure the in grub, so that would be append=usbcore.autosuspend=-1 in syslinux and freinds, but that did not work either, and supposes that usbcore is compiled into the kernel, which I am unsure about.

I could of course locate all power/control files, and put them all in a script, but if you are aware of any other boot parameters I might use to make sure the system runs at full throttle at all times, that would help a lot...

Thanks again,

GKM.

[rodbrogden]

I was trying to install e17 and I messed up (corrupted) my fatdog64 700b2 instalation. Since I'm still very new to this distro, I didn't realize that you don't, by default, have multisessions... so, it appears that I can't recover my previous session. Is this correct?

And if the above senario is not possible, would there be a way that I can restore the base system? (I would prefer not to install FD again.) I tried booting without savefile, but when I exit FD, it only lets me save to CD (this seems odd) -- and I want it to overwrite the savefile on my USB SSD.

UPDATE: I tried a few things... I started in savefile=none mode, then I renamed the savefile I was using, then I opened init.cfg and changed the custom line for my default savefile to a new named savefile (fd64save2.ext4). Then I rebooted, and while shutting down created a new hostname, password and savefile (fd64save2.ext4). BUT when the system started (using fd64sve2), FD stalled with errors showing in the xorg.cfg file. I started xorgwizard, but all options including the vesa driver failed to work. It appears that something other then the savefile is the problem...

maybe the latest xorg update is the problem - it certainly breaks my laptop in similar manner you describe ... just an idea

[Ted Dog]

there is a handy utility to setup savefiles and best for new users however there are so many different ways to run fatdog64 and save back changes.
Reminds me I need to ask Kirk and James if there is a limit to number of multisessions for optical drives. I have been using same BluRay data disc for a few months and have a bunch of sessions saved.
Its working great however just asking.

[gcmartin]

... if there is a limit to number of multisessions for optical drives. I have been using same BluRay data disc for a few months and have a bunch of sessions saved. ...

In a prior FATDOG 52x, I ran it for 2 years with the same DVD. I know this is not an answer and understand your question to ask if this is limited, but, on my DVD I did not have problems over that period on that version.

DVDs and BluRay is a viable and safe solution for maintaining individual sessions which can be avoided should there be problems with a single one of them. Also, the fact that nothing is saved unless shutdown, or running an individual write to DVD/Blu can avert many problems we sometime hit during running any individual session knowing it does NOT corrupt the starting base, is a "feat that pays".

Because I boot so little anyhow (stable systems) this is/was a great great feature for FATDOG "Live" users.

@TedDog was/is a proponent of continued use of the multiple sessions approach and see benefit in its use. I, too, see its benefit.

I am hopeful that a manner of controlling when a session is saved, especially for those who develop/test things in their running system is an obvious pattern option should one choose it as the path for session operations. This is probable a good topic outside of the FATDOG testing thread to approach a method of doing so. Further, the work done over the summer to add folder session options, I wonder if this is already in FATDOG for user selection at shutdown.

Hope this helps

[James C]

Been running the latest Tahrpup on this box (multi-session DVD) and decided to try a quick live test of Fatdog 700.Normally run Windows on here so not much more than ootb so.....

Best resolution so far is 1024x768 instead of the desired 1920x1080 and no sound. Did try each of the sound card possibilities..... no luck.Did boot to a desktop with working internet.

Code: Select all

-Computer-
Processor		: 8x AMD FX(tm)-8320 Eight-Core Processor
Memory		: 8077MB (384MB used)
Machine Type		: Physical machine
Operating System		: Fatdog64 [700b1]
User Name		: root (root)
Date/Time		: Thu Oct  9 21:30:31 2014
-Display-
Resolution		: 1024x768 pixels
OpenGL Renderer		: Gallium 0.4 on llvmpipe (LLVM 3.4, 128 bits)
X11 Vendor		: The X.Org Foundation
-Audio Devices-
Audio Adapter		: HDA-Intel - HDA ATI SB
Audio Adapter		: HDA-Intel - HDA NVidia

Code: Select all

-PCI Devices-
Audio device		: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) (rev 40)
VGA compatible controller		: NVIDIA Corporation Device 1381 (rev a2) (prog-if 00 [VGA controller])
Audio device		: NVIDIA Corporation Device 0fbc (rev a1)
Ethernet controller		: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09)

Code: Select all

Chip description:
VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750] (rev a2) 

No real problems on my older Nvidia hardware though.