TinyCorePure64 with AppImage

[LonnieTC]

Hi All,

I am very new to Tiny Core Linux but think that it could be very useful for a project that I am working on and for which I am build from on Ubuntu 18.04 (64 bit).

To that end and for some initial testing, I loaded up the TinyCorePure64 on my VirtualBox and booted things up just fine. I figure out how to add apps and libraries. Let me just say that I absolutely love the minimalist approach that TC takes, so I loaded in Firefox with no problems at all.

I wanted to try a test on Linux Portable Apps from "AppImage" (https://appimage.org/) for which I went to "Try Subsurface Appimage (64-bit)" (https://subsurface-divelog.org/downloads/) and grabbed the "Subsurface-4.8.4-x86_64.AppImage" (https://subsurface-divelog.org/downloads/Subsurface-4.8.4-x86_64.AppImage)

All went well at this point for the download into TC so then, as the site says, I open a TC terminal and went into "Downloads" where I changed the Subsurface to executable with "chmod a+x Subsurface-4.8.4-x86_64.AppImage" and then tried to run it

./Subsurface-4.8.4-x86_64.AppImage

This is where I needed more libraries.  First I need to add fuse.tcz, then libusb.tcz, followed by libgpg-error.tcz without any problems by loading one and trying to run after which TC would say that is needed another library.

All was going well until TC said that it needed "libp11-kit" but it turns out that there is no such library in the TC application loader.

My goal in all of this is to see if I can get Linux Portable Applications to run in TC.

Any ideas on how to fix this?

Thanks in advance

[Juanito]

Did you try the p11-kit extension?

[LonnieTC]

yes, I tried to locate it to load, but it was not there.

[Juanito]

It is there - p11,  not libp11..

[hiro]

i'm curious about the topic, but i don't see why they call it "portable" if it requires so many dynamic libraries to be present?

[mocore]

i'm curious about the topic, but i don't see why they call it "portable" if it requires so many dynamic libraries to be present?

i was just reading about this `AppImage: Linux apps that run anywhere (appimage.org)` @ https://news.ycombinator.com/item?id=11187198

this comment

Seems unnecessarily complicated.

A script like this gets you 95% of the way there:

  mkdir AppDir
  mkdir AppDir/bin
  mkdir AppDir/data
 
  cp $INSTALLDIR/app AppDir/bin
  cp -r $INSTALLDIR/data AppDir
  cp `ldd AppDir/bin/app | grep -o '\W/[^ ]*'` AppDir/bin
 
  cat << "EOF" > AppDir/app
  #!/bin/bash
  SCRIPT_PATH=$(dirname $(readlink -f $0))
  $SCRIPT_PATH/bin/ld-*.so.2 --library-path $SCRIPT_PATH/bin $SCRIPT_PATH/bin/app $*
  EOF

(Sometimes I wonder if people make a big mystery of Linux app distribution on purpose, to discourage distribution outside of proper, secure channels.)

reminded me of this topic on the tcl forums 


this one also caught my attention

AppImageUpdate lets you update AppImages in a decentral way using information embedded in the AppImage itself. No central repository is involved. This enables upstream application projects to release AppImages that can be updated easily. Since AppImageKit uses delta updates, the downloads are very small and efficient.

https://github.com/AppImage/AppImageUpdate - 'lets you update AppImages in a decentral way using information embedded in the AppImage itself.'

[hiro]

haha, i agree it might be on purpose, but hard to imagine they would have any noble reasons for it.

[vinceASPECT]

So....

Do linux portable applications "generally" , with little extra effort, RUN inside TCL...?

i see that script in this thread.........should one always use that TCL script at the very least
with appimage programs?

thanks

VIn.

[hiro]

i doubt it. seems to me like marketing. docker solves it by including the whole userland part of the operating system with all dependencies: glibc, and *much* more. duplicated once per docker image!
if i understand correctly appimage tries to avoid this, but that should make it less portable.

[vinceASPECT]

Hiro,

Thankyou for replying in good time.

Yes, you seem to know what you are talking about. 

Docker is also free.  WHere-as time spent sorting out masses
of potential userland issues can't be....can it.

The way sometimes to do things like portability, is take leverage or
some free cloud service . (there are some incredible deals at a few cents
per hour for server's live. )

TCL once had a sort of "appimage" approach when there was an extra Repo
of "self contained" single extensions.  The repo was in tandem with the regular
Repo.  True the programs were "larger" over-all but it  did work good.

That morphed into "Dcore"  distro maybe......?....

thanks again ........

Vin

[hiro]

i agree, in the end it's all about time spent/lost.
it all depends on what kind of software you're going to run, how many dependencies there will be, how much those overlap, we often  speak of dependency hell for good reasons.
i don't like the overhead of docker most of the time, i don't like having one docker per application most of the time, etc., still i see how sometimes downloading and running a docker thing will take less time than piecing everything together manually in your plain distribution. especially on tinycorelinux you often have much less available packages or some outdated stuff (on debian you also have that latter problem, sometimes even worse than tcl;)).
some compile everything that doesn't exist or work manually and upload it to the distro's package collection,
some get around by running multiple distributions in parallel and taking as much as possible from what's already there,
and then some try to do everything with docker, but docker packages also don't exist for every package!
so yeah, it depends.
try it out if you're really curious. i avoid all this stuff as much as i can, haha.
short while ago when others decided for me, i used  "anaconda", for that numpy jupyter notebook software package dump...
funnily enough it ran very well on tinycorelinux, while all the others who came with windows had weird problems bec. of some random software version differences and some resulting dependency hell. also it didn't work at all inside my alpine chroot - because it had the wrong libc (from musl).
try to be pragmatic about it and try to reuse provenly working setups when you can, but don't depend on it, most of the time you'll stumble over something and you regret trying and either it would have taken less time to do it all manual, or the total time is the failed first approach PLUS the revert to manual approach. it's a mess, haha.
of course i doubt it helps that there is now thousands of competing container tools, package collectoins, distros, package managers, virtualization methods, etc. etc., cause this is just scattering all the ressources and nobody works together into the same direction.
but yeah, that's freedom and open-source, also some people are even admitting they are delibirately building walled gardens, so those are also corporations with their strategies and some egocentric individuals in your way

[vinceASPECT]

Hiro (forum)

Totally accurate summary of yours . ......agreed.

There are some "virtualization" things that extend to just "dumping" and re-cloning the entire operating systems with the (already) "stable" installed apps ..............

(should you need to do it......)....infinite times. ....OR Less are possible.There is no limit.

These systems are flawless. They are the ultimate solution to managing and
maintaining stable systems....... ye

quickly ........... efficiently.

I would further like to add here that ALL global computer systems in the desktop computing arena have the same single "design flaw".  This flaw exists because , in part, nearly all humans  copy each other...........( hardware makers)
 
The FLAW is that computers should contain TWO IDENTICAL hard drives.
The system and all of it's activity should be permanently mirrored in real-time
on two independent drives. 

Anyhow Hiro and Forum, there are tools on the major platforms that allow unlimited OS's to run on the same single hardware. It's fast to CLONE and re-clone a system or start with a fresh Virgin System for work.

THey don't rely on any software Stacks..... meaning to say, you always have a "default" Virgin OS (sitting in the parking lot on HDD).........and it's infinitely clone-able on that same single hardware
(anything is possible)

You can  double up....or multi up on that Virgin parked car.....whenever you like....putting passengers into some cars......other's adding turbo's to the engine....
(metaphors for using APPS on the systems)

......other(s) of your infinite systems can be for doing other "mission critical" things such as ..... (you fill in the blanks)

......those approaches are good because you can have unlimited versions of OS's all on the same single h/w drive or drives.  (size is your only limit)

You can have OS's for using for Virtual Machines and testing etc.

So ..............there is still weight in the idea of cheap rental  (few cents hour) of private servers in the cloud.  Many services exist for that.....where.

Your not having to manage the hardware....manage the software STacks that are prone to issues.........you just use the distant remote services.



Thanks

Vin