Are there any jessie Dpups-64 in existence?

Using applications, configuring, problems
Post Reply
Message
Author
Lassar
Posts: 235
Joined: Tue 08 Jul 2014, 20:01

Are there any jessie Dpups-64 in existence?

#1 Post by Lassar »

I have been trying out xenialpup 64.

The one problem I have with it, is that it's iso is 80 to 100 megabytes bigger than tahrpup-64.

Not only that, but it seems to have less applications on it.

I am thinking that a jessie debrian pup will be way smaller then a xenialpup.

The reason I want jessie is concerning https problems. I found tahrpup-64 has ssl problems in kodi.

I think that debian pups are probably smaller then ubuntu pups.

So is there any jessie Dpups out in existence?

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

#2 Post by mikeslr »

Hi Lassar,

IIRC, the only "JessiePup" are pupjibaro, and and the mods of Mx-16. They are only 32-bit OSes.

Perhaps you should consider one of the DebianDogs: : http://murga-linux.com/puppy/viewtopic. ... 473#876473. Both are debian Jessie. The first link includes Chrome in three forms: a regular version which runs as root and two security versions. The second link is to an older build using firefox. Don't be particularly concerned about (a) the older version; (b) the absence of any built in applications you may want, or (c) questions regarding size.

These access debian repositories via synaptic and apt. Updating to the latest and adding any of the myriad applications --or just the libraries you may need-- of the debian Jessie repos are a couple clicks away. The "debiandogs" in general are frugal in their use of RAM; and are constructed to provide an analog of "SaveFolders".

In operating, they are very much like Puppies. But there would be some learning required to make the most of their tools to create and use SFSes.

mikesLr

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#3 Post by rufwoof »

From a cursory glance, looks like fully extracted xenial is around 1.3GB compared to 1.2GB for Tahr and where the xenial has around twice as many lib files (1839 files, 123MB) as tahr (968 files, 40MB) ... which goes some way to make the difference.

When looked at from a extracted perspective Tahr has a few broken sym links one of which is libssl.1 missing target libssl.1.0.0 - that are present in the xenial version (others missing targets in tahr include libcrypto, libpcre, libudev) ... so perhaps ssl isn't the only thing 'broken' in the tahr version.

The targets are there, but hard linked (/lib/libssl...) rather than soft linked. Perhaps try deleting the libssl.so.1 sym link and recreate it as a soft link

cd /lib
ln -s libssl.so.1.0.0 libssl.so.1

and see if that fixes tahr's kodi ssl problem

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#4 Post by rufwoof »

mikeslr wrote:the debian Jessie repos are a couple clicks away. The "debiandogs" in general are frugal in their use of RAM; and are constructed to provide an analog of "SaveFolders".

In operating, they are very much like Puppies. But there would be some learning required to make the most of their tools to create and use SFSes
Pretty easy Mike. Best to use programs only installed from the Debian repository and for a command line version you can run something like

apt-get update
apt-get install libreoffice

The first is just to update the local database of packages, the second installs the named program (libreoffice in that example).

Behind that packages (programs) come down as .deb files ... a bit like a compressed archive file, which apt2sfs in effect convert to sfs's. i.e. with the debiandogs you can fire up debiandog and create a sfs using apt2sfs ... to perhaps create a libreoffice.sfs for instance.

Once you have a sfs you can load it simply by dropping it in alongside the main squashfs (/live/01-filesystem.squashfs) as all .squashfs files in that /live folder get loaded at startup in alphanumeric sorted order (one of the reasons I believe it was Toni specifically named the filesystem.squashfs as 01-filesystem.squashfs ... i.e so it gets loaded first). So via choice of naming you can in effect choose which sfs's get loaded and in what order.

In boot-3 systemD style that I use its the same, but if you create a filesystem.module file in that /live folder then only the squashfs files named in that will be loaded (in the order listed in that file).

IIRC debiandog also has the capacity to load sfs's 'on-the-fly'. It's packed with good sfs tools/utilities ... but the extensive range of choices can make it look overwhelming.

For kodi for Debian Jessie ... that's in the backports repository (backported from a later version of debian that's on the road to being incorporated as part of 'Stable' debian). Which means you have to add the backports repository to /etc/apt/sources.list

I changed my /etc/apt/sources.list to look like

# kodi (uncommented before update and install kodi, then commented out again
deb http://http.debian.net/debian/ jessie-backports main

I commented that out after having installed kodi i.e. after having run
apt-get update
apt-get install kodi

The Debian backported version of kodi isn't the latest version ... but it works well for me.

In some cases not all libraries/dependencies will get installed. Another 'trick' is to run
apt-get -f install
which 'fixes' any broken installs (downloads and installs missing dependencies).
Another useful trick is you can use debians 'debsums' command that validates the md5's of all your installed versions with the central repositories versions i.e. validates that they are the same. Handy if you suspect your system might have been hacked/compromised.

Debian's nice if you're using hardware that isn't the most recent where otherwise drivers/modules might be missing. Especially for security updates i.e.
apt-get update
apt-get upgrade
updates your system for all the latest/recent security patches.

Yes larger footprint, but given that disk space is inexpensive nowadays 2GB fully extracted size compared to perhaps 1.2GB ... isn't a particular issue for me (I can live with a main squashfs filesizes of perhaps 400MB compared to perhaps 200MB).

Mostly I don't now bother with sfs's myself. I'm on a 100MB link so pulling things in directly from the debian repository is pretty quick. For instance I can boot just a textual only command line version of debian and install xorg and openbox ... in a matter of minutes ... and have a gui desktop (startx and you're into a basic openbox gui session). Then add other programs to that (firefox, libre ...etc) also pretty quickly. Or whatever alternatives you might prefer (xorg, rox, jwm ...etc.).
Attachments
k.jpg
(26.98 KiB) Downloaded 144 times

Lassar
Posts: 235
Joined: Tue 08 Jul 2014, 20:01

#5 Post by Lassar »

rufwoof wrote: When looked at from a extracted perspective Tahr has a few broken sym links one of which is libssl.1 missing target libssl.1.0.0 - that are present in the xenial version (others missing targets in tahr include libcrypto, libpcre, libudev) ... so perhaps ssl isn't the only thing 'broken' in the tahr version.

The targets are there, but hard linked (/lib/libssl...) rather than soft linked. Perhaps try deleting the libssl.so.1 sym link and recreate it as a soft link

cd /lib
ln -s libssl.so.1.0.0 libssl.so.1

and see if that fixes tahr's kodi ssl problem
Tried doing that and ran into this problem.

ln -s libcrypto.so.1.0.0 libcrypto.so.0.9.7
ln: failed to create symbolic link ‘libcrypto.so.0.9.7’: File exists

Tried "rm libcrypto.so.0.9.7"
file does not exist.

So I took rox filer and deleted it.

ln -s libcrypto.so.1.0.0 libcrypto.so.0.9.7

ln: failed to create symbolic link ‘libcrypto.so.0.9.7’: File exists

I used pfind, that file does not exist.

Any ideas on this?

Post Reply