Puppy Linux Discussion Forum

A Funny Thing Happened on the Way to the Forum*. I got distracted.

While those who know what they are doing are engaged in creating the next generation of Puppys, I decided to provide the elixir by which moribund Puppys could be rejuvenated. See, viewtopic.php?p=70584&sid=88252588ad817 ... 18c#p70584 .

Like all mystical journeys the path requires learning many new incantations and is arduous. I had to take a respite, and while respiting had this thought: “What’s the sense of having a Tahrpup64 with a new heart if it still had the same old, worn-out, appendages? Might as well fix those as well.”

Remastering is something I’ve done a couple of times. So on the road with Tahrpup64_6.0.8 (with a new glibc) I took Tahrpup64 to a health spa. This Tahrpup64_6.0.7 is the result. If you’re interested, you can get it here, https://www.mediafire.com/folder/7yxedk ... up64-6.0.7

I’m posting from it now.

What can this physically fit Puppy do? First off, it is a sprinter, light on resources. On my desktop it booted up only using about 123 Mbs of RAM. It opens and opens applications faster than “newer” Mainstream 64-bit Puppys. With ozsouth’s recent 5.4.221 kernel, it has the up-to-date bug fixes and security patches and can use overlays –see first picture . Naturally, it can drink MikeWalsh’s portable-wines; so the world of Windows 32-bit programs is open even if you don’t (you can) SFS-load the 32-bit compatibility SFS available via Quickpet. Indeed, all the applications available to Tahrpup64_6.0.5 can be installed via PPM, Quickpet or otherwise. Among those are PupMusic, pupradio, dvdstyler, imagination and guvcview. But I’d recommend caution. Some other applications may be older than they need to be.

Of course, the latest Office Suites work. Also OOTB it can run the following Web-browsers and other internet tools:

I recommend that you use MikeWalsh’s portable web-browsers which you’ll find here, https://www.forum.puppylinux.com/viewforum.php?f=90. Or you can jump to a particular thread from his Complete List of Portables here, https://www.forum.puppylinux.com/viewto ... 734#p48734. I don’t think (untested) any of the Chromium & Clones will auto-update even with the devx sfs-loaded. Of Mike’s portables based on Chromium –Google-chrome, Brave, Vivaldi, etc.-- only Opera could not be used. It requires libnghttp2.so.14 and I no longer support the use of Opera. Brave is a hoot. Strongly recommended.

Of ‘Mozilla’ and web-browsers forked or built from it:
The latest Seamonkey and Palemoon work fine. But I haven’t yet tried updating them. So does Waterfox-Classic which I prefer sufficiently that I’ve posted instructions in Additional Software>Browsers and Internet on how to roll your own portable. But the ‘non-classic’ version of Waterfox is based on the latest firefox-quantum. The current version of Tor –which is based on firefox-- opens and closes but I haven’t used it nor updated it.

Slightly older versions of firefox, firefox-esr, librewolf and waterfox worked fine. But something has recently changed. Perhaps a newer glibc is required; or perhaps only a change in glib-schemes. Neither the latest Waterfox (not ‘Classic’) nor Librewolf would open. firefox and firefox-esr opened and would shut-down properly using quit from the Menu. But they would not shut-down via the ‘x’ at the Top-Right and hung when --after updating-- I again checked for updates.

The latest Seamonkey is built in. If you click the launcher on the Taskbar you can select (only) it to open a web-browser. I recommend waiting. Before creating a SaveFile/folder you may want to open seamonkey by file-browsing into /opt/seamonkey and clicking the smky script; then use seamonkey to download a different/alternate web-browser. The only thing located in adrv_tahr64_6.0.7.sfs is a fully portable seamonkey. If you don’t use your system to open Seamonkey before creating a SaveFile/Folder, there will be nothing else on your system relating to it preserved and you can delete/move the adrv without leaving any trace of seamonkey on your system. Also, once you have a SaveFile/Folder you will also have a Home-partition. You can drag the seamonkey folder from /opt onto /mnt/home, select move, then drag it back and select symlink(relative). Then the only thing on your system will be the symlink and you can update Seamonkey (now on /mnt/home) without having to perform a Save to preserve that change. Cache from the web (roughly 100 Mbs per web-page) will also be written there rather than occupying RAM.

I recommend saving Seamonkey in that manner. It still is the web-browser using the least RAM, has a component for obtaining mail and another for reading AND editing html files. And it can play Youtubes. It may not be flashy. But it does the job.

Both MikeWalsh’s Freetube and Leonflix work.

Getting on line: The three Networking components work. But frisbee seems to require greater wifi strength. SNS had no problem establishing a sufficient connection to record my WPA password on my desktop computer (far from the router) while frisbee was unable. frisbee, however, had no difficulty doing so on my laptop which is closer to the router.

Tahrpup64-6.0.7 could be a graphics workhorse. Special mention is made of gimp&mypaint-x86_64.sfs you can obtain here, http://distro.ibiblio.org/puppylinux/pe ... es-tahr64/. Just having learned that Lazpaint, despite its small size, can mix raster and vector graphics through layering, I’ve built it in. Blender 7.6 via Quickpet and a downloadable 2.8.3 from here, https://download.blender.org/release/, works –perhaps even later versions --but MikeWalsh’s 2.9.3 portable segfaults. MikeWalsh’s portable inkscape works. You can obtain Lightworks from https://oldforum.puppylinux.com/viewtop ... 3#p1058313.
You’ll have to track them down both FreeCad appimage v. 0.17 and Krita 3.0 Mesa 10.1.3 which also work; as will Hugin Panorama Stretcher circa 2019.

Video-Editing: Good for simple work, less so for major projects. The latest avidemux_2.8.1_legacy.appImage from https://sourceforge.net/projects/avidem ... mux/2.8.1/ has some nice new features. And Mike’s Losslesscut-portable also functions. But while there are other alternatives, if I had to engage in creating a long video from mixed sources –despite its reputed significant learning curve-- I’d chose cinelerra-7.1-x86_64_trusty.tar.xz links here, https://www.videohelp.com/software/Cine ... d-versions. It also has the reputation for being well-built and stable.
There is, however, Kdenlive-17.04.1b-x86_64.AppImage from https://www.videohelp.com/download/Kden ... WbDVHbNMTQ you might try. Or Flowblade_Movie_Editor-1.8.0.glibc2.15-x86_64.AppImage if you can find it. I couldn’t. But both opened and seemed functional. If used, however, I’d recommend backing up your work frequently. Although there's an Openshot via Quickpet, it's python bites and I couldn't tame it.

Rounding out my exploration of what applications worked OOTB under Tahrpup64-6.0.7 are peazip 8.1.0 https://sourceforge.net/projects/peazip/files/8.1.0/ and Calibre.AppImage downloaded from https://apprepo.de/appimage/calibre.

Feel free to wander beyond my path and tell us of your own adventures. I return to my quest, wondering if a heart-transplant will do it in.
===-===-
* If you've never seen the movie, find it somewhere on the Web. You're in for a treat.

Tahr-6.0.5 and Tahr64 are two of my favorite distro's. Solid as a granite cliff. Blazing fast on an Optiplex 990

Now this is curious. I distinctly recall examining kernels and choosing the 5.4.221 by ozsouth a couple of week ago when I started the upgrade-glibc project. Although I don't compile, I figured some else might want to. So one of the reasons it was chosen was because there were accompanying Kernel Sources and Headers. I didn't mention that in my first post so decided to provide the link to those here.

Vmlinuz definitely identifies as 5.4.221 (albeit no 'oz' designation). See pwidgets in screenshot in OP. Not only can I not find a post relating to this kernel, I can't find it on archive.org. And none of my other Puppys nor my kernel folder in storage has it. And it's not mentioned in my notes. I wonder where it came from.

The OP shows Phil Silvers as the conniving Marcus Lycus. But I'm beginning to feel more like clueless Erronius played by Buster Keaton.

@mikeslr - 5.4.221 is not one of my kernels - I had trouble compiling any 5.4 after 159, due to lack of aufs updates. It does have overlayfs=y, but you need a special initrd.gz to use that, & save file/folder doesn't work ootb with overlayfs. This looks good. For security, probably wget, openssl, curl & busybox could be updated.

dimkr made a version of Fossapup64-CE 9.6 that was using the 5.4.221 kernel
viewtopic.php?p=71202#p71202

I have no idea where the kernel he made is located if it still is.

mirrored here: https://archive.org/details/Puppy_Linux_Tahr64

bigpup wrote: ↑Sat Nov 12, 2022 3:38 am

I have no idea where the kernel he made is located if it still is.

https://github.com/puppylinux-woof-CE/w ... el-kit.yml

Thanks, all for clearing up the mystery. I was exploring an earlier build of dimkr's Fossapup64-CE 9.6 at the time I set out on this journey. I feel less Erronius. . dimkr's kernel worked well on my systems and also being new I must have chosen it rather than having to download one of ozsouth's. It's hard to remember what I did 2 weeks ago, let alone what I thought.

In the meantime, since my last post --before discovering your posts-- I've tested the following of ozsouth's kernels with Tahrpup64-6.0.7 on my desktop and laptop: 6.0.6, 5.19.11, 5.10.153 and 5.4.159. The testing was limited, just whether the system would boot to desktop, wifi connections could be established and youtube music videos played with sound. All passed. All can be obtained with corresponding Kernel Sources and Headers from here, https://archive.org/download/Puppy_Linux_Huge-Kernels/.

The 5.19.11 and 5.10.153 kernels were chosen for testing because ozsouth has reported that 'It now seems that kernels 5.10 & 5.19 are the only ones currently supported for Aufs. (Others MAY work)'; the 6.0.6 because it is his most recent in the 6 series and I wondered if it would; and the 5.4.159 because I suspect it was the one I was thinking about before using the 5.4.221.

Thanks, oz, for point out that your kernels constructed to work with overlays do ".. have overlayfs=y, but you need a special initrd.gz to use that, & save file/folder doesn't work ootb with overlayfs." I'm guessing that the 'ao' designation in a tar.gz identifies those which can work with either or both aufs and overlays.

Thanks, ally, for archiving Tahrpup64-6.0.7 and for all the other assistance you provide to Puppy.

I've not going to remaster and re-upload 6.0.7. As said, dimkr's kernel works fine. Anyone needing a different kernel now will know where to look. What kernel I'll use for 6.0.8 --if there ever is a 6.0.8-- will depend on future developments.

Reasons for discontinuing this project and the one from which it was forked --up-grading glibc:
The primary reasons are that (a) at best it would provide little additional value, that being only the ability to run all current web-browsers rather than just the reasonably adequate list mentioned in prior posts; (b) newer woof-built Puppys use RAM as efficiently, or almost so; and (c) employing woof is much easier to do than what has to be done to upgrade an old 64-bit 'debian-or-Ubuntu-based' Puppy's glibc.

Often as I worked on these projects I was reminded of the frankenpup. It's easy to do. For example, take the puppy_tahr64_6.0.5.sfs, rename it puppy_vanilladpup_9.2.19.sfs, edit the files which identify the location from which PPM can download applications, and with a little luck you have a boot-able frankenpup. Easier, still, is just to swap Vanilladpup's kernel for tahrpup64's. Both procedures accomplish the same thing, and fail to accomplish that which was here desired: updating glibc because glibc is located in within the puppy_XXX.sfs file-system.

Recommendation for future woof-Devs: modify woof to build a 'gdrv --or pick any name you want-- which will contain glibc, gtk-X and all the foundation libraries required by such web-facing applications including and such as openssl, wget, uget, and transmission. And the initrd which would use such additional 'alphabet' drv. [To use an additional 'Alphabet.drv', there has to be code in initrd for that. In comparing tahr64's initrd to that of newer 'debian/ubuntu' Puppys, not only has there been a change in initrd's code; there also has been a change in how file-structures expected by those codes are organized]. As I worked on these projects, it occurred to me that it made little sense to update glibc & openssl without also updating wget, uget etc. I had doubts that without something more the newer foundations would not be able to use the older applications. While thousand of file replacements were involved, the packages that provided the replacement files were these comparatively few:

bash-completion, ca-certificates, curl, glibc, glibc-locales, gnutls, gtk+3, libcurl3-gnutls, libevent, openssl, package-deb-ignore.list, transmission, wget, wireless-tools, and xserver-xorg.

You'll know better than I, but I saw very little over-lap between the files required by web-facing applications and other applications except, of course, glibc and glibc-locales, themselves. AFAIK, only one of the foregoing which can not have an alternate within the operating system is glibc, itself. That is, for example, there could be within an operating system both a gtk+3 and a gtk+4 or gtk+3.5.

The small additional 'weight' that proving some duplication--in the core & the 'gdrv'-- of file-systems would entail would be more than out-weighed by the benefit of being able to upgrade glibc and web-facing foundations.

While employing a 'gdrv' from the outset makes sense, creating one for Tahrpup64 didn't. There its purpose would not have been to provide the necessary files but rather to have priority over files already present in the base file-system. Might as well just replace the latter, especially as that would eliminate the necessity of revising Tahrpup64's initrd. And as I was performing the operation manually, it also gave me the opportunities to remove no longer required files and to fix symlinks broken by their removal.

Well, "the operation was successful except that the patient died". One boot-up the puppy with a new heart failed to sync requiring a hard shut-down to put it out of its misery.

Note to future amateurs without masochistic inclinations: learn to code. [Do as I say, not as I do]. You'll find text files identifying what applications were built-in in /root/.packages under old Puppys and /var/packages under new. The contents of those text files spell out each file and its location in the system. They are created by Woof and Package-Managers, and can be used by the later and Remove-builtins. jpeps's gnewpet, https://oldforum.puppylinux.com/viewtop ... 27#p598673 can also be used under 'old puppys' to automate the acquisition process by reading the contents of such files. Unfortunately, gnewpet doesn't run under (some) new Puppys. [May be the result of the change over the last 10 years in bash-dialects]. At any rate, it would be more efficient and far less painful to automate the process of obtaining files from one operating system in order to use them in another than to do so manually.

Once bitten, twice shy. I ain't gonna do it again.

Running as hell.

Some small errors detected but It is fantastic (SPEEEEEEEEEEEEEEEEEEEEEEEEEEED ))))

Thanks a lot for your good work.

Nice one, seems little faster than other pups...
after downloading from PPM, when I launch gthumb from terminal I get this. Any fix for this?

Hello.- I found another error.-

When you wanna include an image and you gonna search for it at your hard disks, the program doesn't include names but squares.

I think it could be some problem with letters depending on language....I DON'T KNOW.- good work.

----------------edited-----------------

It's not because of the language.- I used English as main language and it continues happening.

----------------------------------------

Another observation,.- When you restart Graphical server, it looses all your modifications, and it goes back to the original wallpaper and you loose all your shortcuts.- (image)

____________edited 2__________

I don't know why, but some puppies are including it, so it could be a good idea add this program to your puppy.

I find really useful the program PUPSHUTDOWN 3.0, this way when I finish my puppy session, I don't need to shut down, I can suspend it to memory and it starts again in miliseconds and the energy consumtion is minimun.

I suggest you to include this program in future releases.

https://oldforum.puppylinux.com/viewtopic.php?t=56077

PupShutdown Manager enables menu-like access to sixteen common functions that one may find helpful when closing a Puppy session. https://www.smokey01.com/radky/PupShutdown-3.0.pet

Hi everybody:

@mikewalsh yesterday when working I saw that vanilladpup promise better internet browsing because it saves DNS .

Is that possible to do this with TAHR PUP 6.0.7 .....

I wanna try vanilla to see if there is so anounced speed.

Thanks a lot.

(Do you think this improve internet browsing speed a lot... Thanks)

Hi pp4mnklinux,
About gThumb's glibc problem. Remember that updating Tahrpup64's applications was initiated as a companion to updating its glibc. But I discontinued that project as (a) not worth the effort as many good, RAM efficient Puppys, are now available and (b) beyond my capabilities.

I'm pretty good at understanding how systems work but have no ability to learn languages. Often I can follow what others have written --if grep, awk or similarly code related verbs are not used-- but that's not the same as actually 'speaking' the language; more like an algebra problem. An even algebra problems can be daunting if I have to remember how a lot of variables relate to each other. Updating glibc requires deconstruction of the initrd, modifying its code --in the language of bash-- then repacking it.

I've attached a screenshot of the applications I accumulated which worked under tahrpup64. Note among those is an older version of XnView_MP. That I kept it suggests that it should run and provide an acceptable replacement for gThumbs. It can be found here, https://download.xnview.com/old_versions/XnView_MP/. Might needs some libraries (I don't recall).
If you're interested in any of the applications in the screenshot which are SFSes, I probably built them at a time before Ubuntu archived the Ubuntu tahr repos. Would be difficult to do today. Let me know and I'll upload them.

The pfind display issue might be that a necessary font is missing. fonts are 'agnostic'. Try adding some.

I have no desire to maintain this Remaster. Frankly, after peebee published the 64-bit compatibility SFS which can be used under tahrpup32, tahrpup32 became a the superior vehicle for computers not able to run modern Puppys: I actually have accumulated far more 32bit applications that will run under it than applications for 64bit tahrpup; and using the 64bit compatibility SFS tahrpup32 can now run 64bit web-browsers. See this thread, https://www.forum.puppylinux.com/viewtopic.php?t=7799

Feel free to take over this further development of tahrpup64 if you want.

mikeslr wrote: ↑Wed Feb 01, 2023 4:06 pm

Note among those is an older version of XnView_MP. That I kept it suggests that it should run and provide an acceptable replacement for gThumbs. It can be found here, https://download.xnview.com/old_versions/XnView_MP/. Might needs some libraries (I don't recall).

Excellent
Not only does this old version (I downloaded the file XnView_MP-0.931.glibc2.17-x86_64.AppImage , which is Version 0.93.1 64bits Mar 7 2019) work OOTB on F96-CE, also the brand new version 1.4.2, released about a week ago and downloaded from https://www.xnview.com/en/xnviewmp/ works great. I love single file appimages. Might also work in Tahrpup64_6.0.7.

MochiMoppel wrote: ↑Sat Feb 04, 2023 9:12 am

mikeslr wrote: ↑Wed Feb 01, 2023 4:06 pm

Note among those is an older version of XnView_MP. That I kept it suggests that it should run and provide an acceptable replacement for gThumbs. It can be found here, https://download.xnview.com/old_versions/XnView_MP/. Might needs some libraries (I don't recall).

Excellent
Not only does this old version (I downloaded the file XnView_MP-0.931.glibc2.17-x86_64.AppImage , which is Version 0.93.1 64bits Mar 7 2019) work OOTB on F96-CE, also the brand new version 1.4.2, released about a week ago and downloaded from https://www.xnview.com/en/xnviewmp/ works great. I love single file appimages. Might also work in Tahrpup64_6.0.7.

@MochiMoppel @mikeslr xnview seems to be more full featured than gthumb and runs well in FP64. In Tahrpup64_6.0.7 however I get this ... any ideas on how to fix?

@gychang :-

This issue with not finding 'xcb' even though it's where it's expected to be is an old, long-standing problem, Greg. I never have been able to get to the bottom of it.

The nearest I can make out, it doesn't seem to occur if you install your QT stuff from the PPM. If you use one of the multiple QT packages floating around the forum, 9 times out of 10 this will occur.

This appears to be one of those times when you really DO have to use dependencies specifically compiled for a given kernel/glibc set-up..... In some respects, Qt is one of the fussiest items we use in Puppy.

That's all I can suggest, mate.

Mike.

mikewalsh wrote: ↑Sun Feb 05, 2023 2:31 am

@gychang :-

This issue with not finding 'xcb' even though it's where it's expected to be is an old, long-standing problem, Greg. I never have been able to get to the bottom of it.

The nearest I can make out, it doesn't seem to occur if you install your QT stuff from the PPM. If you use one of the multiple QT packages floating around the forum, 9 times out of 10 this will occur.

This appears to be one of those times when you really DO have to use dependencies specifically compiled for a given kernel/glibc set-up..... In some respects, Qt is one of the fussiest items we use in Puppy.

That's all I can suggest, mate.

Mike.

@mikewalsh thanks for your input Mike.

@ gychang. You'll notice in the screenshot that there's a Qt5-5.5.1 SFS. Examining it revealed 'xcb' plugins. It's likely that in order to run xnview I had to load that SFS. As I don't think the Qt5 platform existed when Tarhpup64 was first published, I may have built by starting with a version from Xenialpup64 and filing in missing libs with symlinks as necessary. I'm reluctant to upload it to upload it as it's 172 Mbs, I'm only guessing it was what was needed, there might have been other things simultaneously needed and, as I said, there are better Puppys which can be run if your computer can support them.

Ubuntu Trusty Tahr was first published around 2013. I'd suggest trying one of the XnViews published around 2014 as it likely had such Trusty Tahr as a target operating system.

mikeslr wrote: ↑Sun Feb 05, 2023 3:40 pm

@ gychang. You'll notice in the screenshot that there's a Qt5-5.5.1 SFS. Examining it revealed 'xcb' plugins. It's likely that in order to run xnview I had to load that SFS. As I don't think the Qt5 platform existed when Tarhpup64 was first published, I may have built by starting with a version from Xenialpup64 and filing in missing libs with symlinks as necessary. I'm reluctant to upload it to upload it as it's 172 Mbs, I'm only guessing it was what was needed, there might have been other things simultaneously needed and, as I said, there are better Puppys which can be run if your computer can support them.

Ubuntu Trusty Tahr was first published around 2013. I'd suggest trying one of the XnViews published around 2014 as it likely had such Trusty Tahr as a target operating system.

@mikeslr :-

Seems Qt5 first appeared on the scene all the way back in the days of Precise:-

https://www.qt.io/blog/2012/12/19/qt-5-0

.....so it was definitely around in the days of Tahrpup. Whether or not Ubuntu actually had it in the repos for Trusty Tahr, I wouldn't like to say...

(*shrug*)

T'other Mike.