Fatdog64-700 beta2 [Closed]

[prehistoric]

I've updated Firefox to 35.01_SSL using binary packages from mozilla, but seem to have hosed all downloads.

I saw there is a flash player plugin 11.2.202.440 available, and have installed that from the ibiblio fatdog repository. This is currently back to displaying the blinking penguin ad in the upper right corner of murga linux pages.

I'm betting my trouble comes from the business of running Firefox as "spot", and confusion about permissions. Since this is peculiar to Fatdog and a few other Puppy derivatives, I think we now need a package for Firefox 35.01_SSL to avoid getting constant complaints. We should also probably plan for a steady stream of browser updates which do not expect to run as "spot" by using Fatdog scripts.

Considering my current lack of success, I am probably not the person to package this.

Added: Oops! Just checked my disk partitions. The problem with downloads comes from zero free space on that partition. There should be gigabytes left, so I'll have to find out where the space went.

Still Later: the problem came from having tmp linked to a directory on the same partition as Downloads, plus a crash on yet another system I was running which left a huge file in /tmp. This just happened to coincide with my upgrade to Firefox and Flash player. Coincidences do happen.

I now have 74 GB free on that partition alone.

[gcmartin]

@gcmartin: thanks for the first-run scripts. Have you tested whether it works with Fatdog?

No, because of the many unique things that FATDOG does at desktop initialization. Beside, this "may" need some tweaking for the good things already done in desktop initialization.

I feel it better for the architects to place this and insure it maps to FATDOG's quality expectaions.

I am sincere in trusting the authors decisions. I am merely a testor and reporter, when possible.

[rufwoof]

Here are copies of mksquashfs and unsquashfs that I compiled today using fatdog that include LZO compression. Not much use for kernel compression as I believe the kernel was compiled with LZO compression turned off ??? i.e. you can't sfs_load a LZO compressed sfs. But ok for general transportation of sfs (such as a alternative to tarball).

I tend to use something like

mksquashfs /somedir ./somedir.sfs -comp lzo -Xcompression-level 1 -noappend

[Ted Dog]

@rufwoof
good or bad I see lz4 stuff in Fatdog647b2, not sure if it is being used, but read or dreamed that JB uses a low compression version for more speed himself but its not setup by default..
So maybe we could investigate lz4HC and the like, talked about in your other posts.

[Ted Dog]

@JamesBond,Cpt. Kirk
Currently bound up downloading T2 on April64, is there a way to use the sfs file created by Quirky7(April64) to run like slacko32 worked. Would save me a lot of headaches!

[rufwoof]

Hi Ted Dog

LZ4 seems somewhat confusing to me. Know little myself about it, but from what I've seen it looks like there are two versions, legacy and 'current'. I believe that later kernels that support LZ4 are supporting the legacy version, not the current version, so for a stand alone lz4 program you have to use the -l (that's a little L) choice, but mksquashfs headers seem to apply the current lz4 approach.

I've seen suggestion that lz4 is 3 times quicker at decompressing than lzo (and lzo is around 3x quicker than gzip, so lz4 is conceptually approaching 10 times quicker than gzip), But compresses less (typically around 20% larger than gzip - and similar to lzo. So overall throughput is suggested as being around twice as quick for lzo compared to gzip and lz4 4 times quicker than gzip. From my own casual tests however that seems to apply to current LZ4 and not so much legacy LZ4 - which seems to be about the same as LZO.

I got confused and opted to simply stick with LZO for its greater clarity/simplicity. Opting to target throughput speed and I found that lzo level 1 was the best choice (default is level 3). Slightly larger files than gzip -1, but decompresses quicker for overall faster 'load' times.

I also read that JB uses something like gzip -1, so you weren't dreaming.

Light/fast compression of pup sfs (and kernel-modules.sfs in fatdogs case), merged into initrd and not bothering to compress initrd (other files are relatively few and small to be bothered with) is a good choice IMO. Less memory load as typically the lzo'd pup sfs will be around half the size of non compressed pup sfs, and about the same (or less) throughput times to that of copying a larger uncompressed file into memory. With zram enabled and set to lzo also ??? (presumable faster as conceptually a direct copy of around half as much data size).

[rufwoof]

A 'problem' is that memory resident FatDog (as how you/me run it) on a multi-core with modest memory is so frecking fast anyway that there's perhaps little to be gained operationally. Blink of a eye response times reduced even by half appear little different.

[Ted Dog]

Ah yes , but on a bottom basement AMD laptop the difference is very noted. Yes on my Intel multicore 3+Ghz server its hardly worth it. but can't set that monster on my chest and compute from bed (which happens a lot, with my M.D. causing me not able to sit-up right )

[rufwoof]

Yes on my Intel multicore 3+Ghz server its hardly worth it. Very Happy but can't set that monster on my chest and compute from bed

I'd bet such a beast virtually weighed nothing - just the added weight of something like Teamviewer.

[olinm]

Flash 0-day vuln

http://www.theregister.co.uk/2015/02/02 ... other_one/

Adobe Flash Player 11.2.202.440 and earlier versions for Linux will all need updating. Adobe categorises the CVE-2015-0313 vulnerability tackled by the update as critical.

Adobe expects to release the Flash Player update sometime this week

[prehistoric]

And I just got through bringing flash player up to that date.

At a much lower level of skill, I'm trying to move an elderly friend off XP and onto some Linux system which will not require daily support from me. We just went through an exercise where I tried to explain what was going on when her favorite radio station was playing when a pop-up said we had to install Silverlight before listening. If its a free Internet radio station, and the music was playing, why do we need Silverlight?

To display more ads, silly.

I won't even try to explain the problem of installing Silverlight on Linux.

[boblark]

Anybody have SmallBASIC and Arduino for FD64?

SmallBASIC http://smallbasic.sourceforge.net/ (but not the MS Small Basic), is a nicely done Basic interpreter that I have used to replace QBasic of old. I used it quite a bit under Ubuntu, with out problems. Has anybody done anything with SmallBASIC?

I read in this forum that JustGreg was pursuing getting an Arduino IDE under FD64. I wonder how this or other efforts are progressing? I currently do Arduino on a laptop with XP, so it is not holding anything up. But, my goal is to move all that to FD64.

[JustGreg]

Hi boblark,

I can not help you with SmallBasic, but, I do have some information on using Ardunio boards with Fatdog64.

The performance of Fatdog64 depends on the board you are using. With Fatdog64 and Arduino IDE version 1.06 (64 bit linux distributed in .tgz archieve), I have no problems with programming and running the Arduino Uno and Nano boards. I have tried the Lenoardo and Mircor boards, their serial interfaces are different from Uno and make things a bit more trying. So if you are new to Arduino, my suggestion is to please use the Uno board until you get familiar with the Arduino IDE, Sketch programming, and using the serial monitor.

It is a different story for Yun Board which requires the use of the newer beta version 1.5.8. The 64 bit version has library problems. It seems to use some 32 bit libraries that not available with Fatdog64. This prevents the IDE from communicating with Yun using either networking or the USB connection. However, I have tried the 32bit version Arduino IDE 1.5.8 with latest Slacko 32 bit version. It does work. The usb connection does work well. However, for the networking version, you need BonJour or equipment services. The Yun broadcasts a UDP packet with its host name and IP address. This is received by the Bonjour application for the operating system and passed to the Arduino IDE.

There are work arounds that I use to experiment with Yun. If you are using the Yun, then we should start a topic post in the programming area. It is really off topic for Fatdog64. I also strongly suggest to not use the Yun until you are very competent with Uno. The Yun is part Linux and part Arduino. Communications between the two sides is very interesting as in the old Chinese curse, "may you have an interesting life". I hold this helps.

[gcmartin]

Assuming FATDOG has a JDK version 8+ available, you can install this Auduino project to assist use/development of Arduino needs.

For 32bit machines to be used for connect/development, the base for Auduino project can be found here by @LazY Puppy, needing only the Arduino project because all other needs are addressed.

Just an idea from someone who know too little about Arduino, except that it can be very useful for sensor measurements and small tasks. Thus, excepting for the idea presented, I am not qualified.

[kirk]

Currently bound up downloading T2 on April64, is there a way to use the sfs file created by Quirky7(April64) to run like slacko32 worked. Would save me a lot of headaches!

Not real sure what you're asking Ted. If you're trying to do a custom build you might want to wait until final. We're planning on a RC release soon. James wrote a build system to compile 700 from source and build the iso/devx/nls. I think James is planning on posting the build system after final.

As far as lzo/lz4 compression goes, I would not recommend that for most. The compression used on the sfs only effects startup times for an application, and then usually only the first startup. When an app is ran the kernel decompresses it and caches it. It will stay in cache until memory starts running low. I doubt many will see any difference between gzip and lzo, unless you have a very slow computer, and then you're likley to have less ram too. The faster/lower compressions lead to bigger sfs files, which are loaded into ram by default. Which means longer boot times for the sfs file to load and programs end up having less ram available, which can slow them down.

[technosaurus]

Lz4 compressed with ultra high compression is typically ~2x faster than gzip, but most people use normal lz4 compression because it is much faster on the compression side. Lz4 is definitely faster for compressed kernel image loading-- even faster than no compression.

Just don't do like some puppy developers and include a compressed initramfs in a compressed kernel image.

[Ted Dog]

@kirk, if it is a block type filesystem any decompression will be cashed by the kernel but last I read squashfs is still not. That iz why I wanted the files to be inside a ext3 filesystem and then squashed for the base2ram = expand kernel option. if stored and used either compressed or not the system should provide a decompress copy for sometime.
Related AMD decompression blocks to one core and causes system to crawl, Changes back to gz or newer lz4 should drop the AMD bottle neck in theory. Thanks for putting in the expand code it allows my under horsepowered AMD laptop perform fast. If FD64 was constructed with a block type filesystem within squashfs and double loop mount speed should improve with same compression system in use, but I see the kernel modules in Fatdog64 for lz4 and looks like the tools are already in the beta2.

[boblark]

Arduino again:
Thanks Greg, you got my Arduino 1.0.5 running. I hooked up a UNO and the quick check of compiling and loading an example all worked fine. I only need the traditional board support, so I'm ready to move in a real project.

For info, I am in the test phase of a remote control for the outboard on my sailboat. It uses a UNO to control two big R/C servos on the throttle and gear shift. A second MIcro Arduino is a dedicated tachometer and it sends RPM to the UNO by I2C and that closes the loop.

Bob

[olinm]

And I just got through bringing flash player up to that date.

At a much lower level of skill, I'm trying to move an elderly friend off XP and onto some Linux system which will not require daily support from me. We just went through an exercise where I tried to explain what was going on when her favorite radio station was playing when a pop-up said we had to install Silverlight before listening. If its a free Internet radio station, and the music was playing, why do we need Silverlight?

To display more ads, silly.

I won't even try to explain the problem of installing Silverlight on Linux.

It would be nice if James & Kirk could add an option to fatdog that on every bootup it downloads the latest version of Firefox and Flash player.

You would only then need to update fatdog if there was a serious package problem with something like SSL.

There are now so many 0-day exploits with Firefox and flashplayer that it's a complete pain having to remaster the image ever other week.

[Volhout]

dear olinm,

The reason I use puppy linux (fatdog now) is that it is the closest thing to "immediately ready for use". It works, fast, and reliable.
It does not nag you with "update X" and such.
It does not (like microsoft) delay startup with 20 minutes becuase the latest security patches need installation.

Keep it that way....
One consistent package, never update (unless you really want to).