So why did I decide to go with a trusty old pplog derivative for this blog?

At first I had considered Jekyll, which runs nicely at Github (see but the problem with that is that each post is subject to a "pull request". Nothing wrong with that except I want to trust the posters here and don't want to have to bother with moderating everything. (And there hasn't been great enthusiasm to post a page, edit some content or even proofread over at As it is I have to approve every poster and commenter but that is all. Once registered here you have free rein.

I also considered a couple of other options, including FlatPress, a php based platform which stores its database in flat files, similar to pplog and derivatives. However, I thought why not go with this? It's clean, simple yet elegant and with sc0ttman's enhancements quite modern. It was quite a bit of work though to add the multi-user functionality and make sure it was locked down.

Of course there are other big platforms like WordPress, Drupal and friends but they are big and cumbersome, require an sql database and more often than not are an enormous amount of work to customise and maintain. With WordPress, yes there are tons of themes and add ons but this creates more headaches. Whose code do you trust? Why can't I get such and such theme looking right? Drupal is the opposite in that there aren't all that many themes available and they are big work to customise.

I have forked the code for this blog as sjpplog_ng on GitHub. As many will know it is written in the perl scripting language which has a large presence in the open source community. Most web servers have perl already installed. If you are a perl coder, or even a dabbler (like me) then feel free to fork the project and offer your code. The original licence is GPLv3 so we have to stick with that.

It has been a long month of web developing getting the main puppy site transferred over to me and developing a nice site (many thanks of course to jamesb, mavrothal and BarryK) and now this blog which is the place for the latest in Puppy Linux news. Now back to real development!

Is there anything more Puppy than pplog?

Posted on 26 Mar 2016, 16:33 by 01micko - Categories: Development
Edit - Delete

No comments posted yet.

Fonte dell'articolo

Fido has been a poor neglected pup.

For many years people have wondered why we use the root account for just about everything. After several complaints, Barry eventually created the fido account that served as the default non-root 'user' to appease those not comfortable with running as root. Much of this was based on Pizzasgood's work in Puppy 4.2.1. Unfortunately, fido hasn't received much love since then and has deteriorated in to an emaciated wreck.

I have decided to do some work on the fido account (rather than put him down) and the first thing I did was create a 'home' dir for fido in /home/fido so there will be no more conflicts with /root. Of course it didn't work too well. I got to a desktop fine, everything on the hardware side working, browsing, text editing worked but no terminal! urxvt, our default virtual terminal application just would not run, so out came the google foo. Turns out that permissions in /dev/ were scewed up, a lot of them; some ownerships too. Of course there will be a lot of other bugs that I didn't investigate but this one was huge, and probably the worst.

Anyway, I think I now have it sorted and will offer a package for testing in a pfix=ram environment soon.

You can follow development in this thread on the forum.


NB: The last poster there before my post of today was by Nooby, our lovable perpetual 'noob'. RIP Nooby.

Posted on 29 Mar 2016, 18:24 by 01micko - Categories: Development
Edit - Delete

No comments posted yet.

Fonte dell'articolo

ffmpeg is an audio/video converter. The basic use is to convert an input file/stream to a different output file/stream. Sounds simple? Yeah, but it's also far more complicated.

Multimedia libs in linux is not unique. You have probably (even if not noticed it) been in touch with gstreamer, sox and libav. Diversity is a good thing, but for a minimalistic distro like Puppy, it means we have to take the hard decisions what to support and what to leave.

These days, ffmpeg matures into something more than just one of the other libs. Simply because some major projects make it their preferred multimedia lib.
- Ubuntu and Debian used ffmpeg some years ago, but switched to libav when it forked from ffmpeg. Now they have switched back to ffmpeg. Puppy based on ie. Ubuntu Tahr had major issues with Puppy-tools built upon ffmpeg, like FFconvert and pBurn. pMusic was never included into Puppy Tahr. Slackware on the other side kept ffmpeg, so Puppy Slacko never had these issues.
- Firefox has from version 44 switched from gstreamer to ffmpeg for multimedia support. In a standard Puppy, gstreamer is only used by Firefox. So in a future release, including Firefox will require less dependencies. Gstreamer is not lightweight, so the iso-shrink will be noticeable.

As mentioned, Puppy already includes apps using ffmpeg, but it could also give us more interesting ffmpeg-based apps. Here follows some load thoughts of different ways to use ffmpeg for new projects. That means new apps/features that not require any new backends/dependencies. But let's start to see how it already is in use:

- The original target for ffmpeg was to convert input file to another output file. This is what we see in FFconvert.

ffmpeg -i /path/input_file.mp3 [options] /path/output_file.ogg

This is also what is used by pBurn to make your audio files compatible before burning an audio-CD and any video file for your Video-DVD.

- Depending on the ffmpeg-package, it may or may not contain the ffmpeg media player - ffplay. This is a simple but very useful mediaplayer for video and audio files and streams. It could for sure have been the default media player Puppy, but atm it does not has any control-gui, or a signal-system for building an external gui. Interesting to see how this evolves in the future.

ffplay -i /path/input_file.mp3

- Instead of sending the converted output audio/video stream to an output file, it is possible to send it further to another command. Technically that means sending the stream to stdout and pipe it to next command. This way of using ffmpeg is what pMusic is based upon: Take whatever audio-file format and convert it to raw audio before sending it to the simple audioplayer (aplay) shipped with the audio driver system - alsa.

ffmpeg -i /path/input_file.mp3" -f au - | aplay

This is another solution than using ffplay, and it is likely to think that this has to be hard on the resources on your system. It is not. And there are 3 main benefits: 1.) ffplay is not always bound to the ffmpeg pack. 2.) We can control the soundcard more accurate through aplay than ffplay. 3.) Only very recent versions of ffplay allows sound-filtering of the input stream.

- The input or output can also be a server (a livestream). This webcam recorder is an example of such use. But in the following example I send the output to a local server.

ffmpeg -i /path/input_file.mp3 -f rtp rtp://

This ffmpeg stream can not be heard until you connect to the server. So, you can (dis)connect to your stream without restarting the audio-file. I have set up this structure for the next pMusic release (5.1.0) to support visualization. ffmpeg has filters to convert audio into a generated video like waves or similar, but managing visualization should not interfere with the main audio stream. Solved by sending the output both the the server and to stdout.
ffmpeg -i /path/input_file.mp3 -f rtp rtp:// -f au - | aplay

Realize than ffmpeg can mix and split inputs and outputs. It's getting complicated, and I stop here...

- ffmpeg supports more inputs than files and streams. It is capable to grab the output of the X-server (What you see on your screen). That means it is simple to build a screen recorder for ie. youtube howtos. I have wondered why no one have found this to be a fun project for their coding. It's all based on one single command like:

ffmpeg -video_size 1024x768 -framerate 25 -f x11grab -i :0.0+100,200 output.mp4

including the sound from your mic.
ffmpeg -video_size 1024x768 -framerate 25 -f x11grab -i :0.0+100,200 -f alsa -ac 2 -i hw:0 output.mkv

- The last example is interesting because it also grabs the sound from the soundcard. Combine this with a local audio server as shown above and you can tweak (soundfilters like /eq/pitch/vibrato/..) the sound in realtime without interfering with the input soundcard stream. Are we seeing a pRack...

- And I have not mentioned that ffmpeg supports basic video editing like croping, scaling, fading, effects, etc.

These are only a few examples of the usage of this awesome tool. And personally, I find it pleasing to see that it most likely will be included into future Puppies. Here are much unused potential. So, girls and guys - go coding.

Posted on 31 Mar 2016, 06:51 by zigbert - Categories: Development
Edit - Delete

Posted on 30 Mar 2016, 10:03 by 01micko
"Nice insight"
It is often little known the power of ffmpeg. I have only ever scratched the surface.

A very nice insight! Thank you.

Fonte dell'articolo

So far I have built a slacko64 iso image with Fido available with his own 'home'. It boots fine and on shutdown nothing is changed in the routine that anyone would notice except that /home/fido is created using /root as the skeleton.

Here is a snap (click to enlarge):

What works:

  • browsing

  • text editing

  • package manager

  • virtual terminal (urxvt)

  • mounting drives

  • word processing

  • spread sheet

  • paint

  • videos (mplayer)

  • music (pmusic)
  • What doesn't

  • drive icon markers inconsistent

  • hot plugging

  • sfs management

  • updates management

  • ptheme

  • menu refresh

  • firewall tray icon
  • This is only fairly initial testing.There is probably a bunch more stuff that doesn't work but much of the gui stuff (gtkdialog/xdialog) will be rectified by adding the following line to the top of the application:

    [ $UID -ne 0 ] && exec sudo -A ${0} ${@}

    - which just pops the "askpass" box to type the password. For simplicity, fido and root passwords are the same - entered at first shutdown on creation of fido.

    So, plenty to do - most of it low level ugly stuff.

    Note: this version of slacko64 is built from the woof-CE xorg branch.

    Posted on 30 Mar 2016, 21:28 by 01micko - Categories: PuppyDevelopment
    Edit - Delete

    No comments posted yet.

    Fonte dell'articolo

    Booting UEFI difficult? Nah. Not at all. Let's do this for Slacko 6.3 (32-bit).

    1. Make sure you have UEFI machine. Machines that comes with Win8 or recent usually okay.
    2. Get a blank flash drive. Format it as FAT32.
    3. Grab a copy of Slacko 6.3 ISO
    4. Grab a copy of Grub2 UEFI bootloader, from here:
    This is for 64-bit machine, if yours is 32-bit (extremely rare) then get
    5. Extract the tarball from previous step, make sure you get a copy of grubx64.efi (or grubia32.efi) from inside the tarball and rename it to bootx64.efi (or bootia32.efi).
    6. On you flash drive:
    - mkdir -p EFI/boot
    - copy bootx64.efi (or bootia32.efi) and put it under EFI/boot
    - Extract the contents of Slacko 6.3 ISO and put the following files to the root of the flash drive:
    * vmlinuz
    * initrd.gz
    * puppy_slacko_6.3.0.sfs
    * zdrv_slacko_6.3.0.sfs
    - on the root of the flash drive, create a new file named "grub.cfg" and fill it with the following text:

    menuentry "Start Slacko" { 
    linux /vmlinuz
    initrd /initrd.gz

    7. If you have Windows, boot to Windows and disable hibernation (aka fast boot, aka hybdrid sleep, etc). Your Slacko doesn't need this, this is more to protect Windows.
    8. Configure your UEFI to disable Secure Boot.
    9. Now boot with the flash drive plugged and tell your UEFI bios to boot from that flash drive.

    You can run Slacko64 6.3 in the same way. Your success with other Puppies may vary, but the process is generally the same.

    PS: In my (qemu) test, mouse doesn't work. But this is something I'm sure Mick can fix later :)

    Posted on 1 Apr 2016, 01:12 by jamesb - Categories: Puppy
    Edit - Delete

    Posted on 1 Apr 2016, 08:15 by 01micko
    "Will this work on ISO?"
    Interesting that it seems so easy.

    As the title asks, I'm thinking that it would work the same. I also wonder if execution could be passed on from syslinux to grub. Then one could have an ISO image that boots BIOS and UEFI with minimal bloat with a syslinux boot menu choice.

    I guess I'll have to build Qemu and find out; also find out what cause the mouse failure.

    NB: looks like the date fix works nicely.


    Posted on 1 Apr 2016, 09:51 by jamesb
    You need to create a FAT disk image. Inside that image, create /EFI/boot and put grub2.efi (renamed) to /EFI/boot/bootx64.efi.

    Make sure you have grub.cfg at the root of the ISO image (not inside the FAT disk image).

    Use this FAT image as the secondary bootloader (the primary bootloader will be syslinux, used for BIOS booting).

    Burn it the way Fatdog ISO builder does it. You can choose either mkisofs or xorriso but whichever you choose, you must use the same command for remaster and save-to-dvd (thus, mkisofs is probably better since Slackware already has the right version - the real mkisofs instead of cdrkit).

    You can switch execution from syslinux to grub, but not from BIOS syslinux to EFI grub, so yeah what you want is not possible. You will need to have a separate syslinux.cfg for BIOS and grub.cfg for UEFI.

    If you want to avoid multiple configurations, you can actually use grub2 as the BIOS CD/DVD bootloader too, but I haven't done this yet, and I can't tell how well it will work or whether it will work with multisession at all.

    Posted on 1 Apr 2016, 10:19 by 01micko
    I will try that.

    What I did actually do though was simply add isolinux.bin and from the original slacko iso image and just built an iso (mkisofs).

    I boots in virtualbox (efi enabled)! However, no X, complains about drivers.

    I have no EUFI machines at my disposal to test.

    Posted on 1 Apr 2016, 15:07 by mavrothal
    I used rEFInd ( for my Macs to boot PD, slacko64 and tahr64. Presumably works in PCs too. Is very simple and flexible allowing multiple OSs, icons, volumes and many other goodies.
    Does Grub2-UEFI do similar things?

    Posted on 1 Apr 2016, 19:32 by jamesb
    "RE: rEFInd"
    @Mick - To run in virtualbox under UEFI you need xf86-video-fbdev. You can get away running in qemu because slacko already includes cirrus driver by default.

    As for UEFI machines, don't be disheartened: both virtualbox and qemu can provide surprisingly accurate emulation for testing purposes.

    @mavrothal - yes rEFInd is nice. It is especially nice if you use it as an installed boot loader (on HDD, or on USB flash drive). The only (minor) inconveniences is, it is not self-contained - you need extra drivers to access ext4, ntfs, and CD/DVD whereas grub2.efi is a single file (like grub4dos), but this is not a problem for an installed bootloader.

    rEFInd also has another small problem when used as CD/DVD bootloader - it can only access stuff inside the EFI fat image. So if the CD/DVD must support both BIOS and UEFI, you will have to duplicate vmlinuz and initrd - one on the CD/DVD root (for isolinux) and one inside the EFI fat image (for rEFInd). This is probably not a problem for most Puppies since their vmlinuz/initrd is quite small; but a big problem for Fatdog with its huge initrd. Rod knew about it as I told him about it back in late 2012 when we first tested. He told me the fix wasn't easy so he decided to let it be. There is also another minor problem which I choose not to discuss here - it won't affect most people.

    Compared to rEFInd, grub2.efi supports multiple OS, volumes, and many other goodies too. It supports graphical background image. But it does not support icons.

    Posted on 1 Apr 2016, 20:12 by 01micko
    "ISO works"
    My iso (slacko- - unreleased from xorg branch, the 'fido' one) works just fine in Qemu with UEFI; mouse and all.

    Booted fast and runs smooth.

    Thanks and Cheers!

    Posted on 1 Apr 2016, 20:25 by jamesb
    "Great news!"
    Finally - Puppy has entered UEFI era.

    Posted on 3 Apr 2016, 12:34 by 01micko
    "Works on MacBook Air"
    I forgot about wife's MacBook! Its an 2012 Air with Mavericks (I think - extremely rare for me to use it!) and everything works ootb! Typing on it now - not bothering setting up email.

    I constructed an iso that boots BIOS and UEFI following FatDog64 iso as a template, with the help screens and a png backdrop. I made a backdrop for Tahr too and a generic Puppy version. I made a mistake and named my image efi.img but that seems to not matter as long as the config can find it.

    Before I booted it here I booted it on my old Dell (core 2 duo - bios) and of course it all worked there, as it has been for a while.

    Too early to commit to woof? Maybe I'll post an ISO first.

    Fonte dell'articolo

    Cerca nel sito

    IRC #puppylinux (popup)


    Entra in chat

    Iscriviti alla newsletter

    Ricevi le notizie più importanti direttamente nella tua casella email (premi invio dopo l'indirizzo)

    Dal blog internazionale

    pMusic 5.4.0

    Version 5.4.0 is released Highlights Improve radio detection by allowing several urls for each radio stations in the index file. This is backward compatible with the old format. A new dead simple podcast frontend is included by default. The heavily improved podcast...