Puppy Linux Discussion Forum

I want to install AnyDesk on FocalPup32. I have noticed that gdebi is available in Puppy Package Manager. I expect that this means I can install gdebi, download a 32bit .deb file from anydesk.com and use gdebi to install it.

Consulting Google I also found a post by @mikewalsh "Anydesk "portable" packages - now running as 'spot' " (viewtopic.php?t=1104) with links to 32 and 64 bit AnyDesk "portable" packages.

What are the pros and cons of the two methods? Does the end result differ, and if so, how?

@Kjellinux :-

Yo.

Um. Okay. Well, the primary difference will be that if you get gdebi up-and-running - may run straight off, might need some tweaking; this has been asked on occasion before, but I forget what's been said - and then use it to install an AnyDesk .deb package, that will then be permanently taking up space in the 'save'.

The AnyDesk-portables, these were put together with a bit of collaboration with another Puppian. I've kept them up-to-date over the last couple of years, but initially these were assembled in the early stages of my starting to explore the whole 'portable' concept.

They're what are known as ROX-Apps; as far as I understand this, it's a special way of packaging software that is specific to the ROX-filer file manager, especially given the way it runs the 'pinboard' within JWM. This packaging method makes these items totally independent of location; if you use ROX-filer in your system, a RoxApp will run from anywhere in the system.....which allows you to run them from, say, /mnt/home, or even from a flash drive. Certainly from anywhere outside the save, thus saving space.

Does that clarify things at all..?

Mike.

[/quote]@mikewalsh

mikewalsh wrote: Sat Jul 17, 2021 11:10 pm

Does that clarify things at all..?

At least it clarifies some aspects.

mikewalsh wrote: Sat Jul 17, 2021 11:10 pm

Well, the primary difference will be that if you get gdebi up-and-running ... and then use it to install an AnyDesk .deb package, that will then be permanently taking up space in the 'save'.

This can be important, depending on the computer specifications. Based on the experience of my project so far though , RAM appears to be the main limitation of older computers, followed by limitations of the CPU. Available space in secondary storage, be it HDD, USB or other appears to be less of a limiting factor.

mikewalsh wrote: Sat Jul 17, 2021 11:10 pm

if you use ROX-filer in your system, a RoxApp will run from anywhere in the system...

On one hand, I can see the advantage of the flexibility and simplicity of this method, on the other hand, it means I can't do it the same way as it's done in most Debian based distributions, forcing me to keep track of a separate method for Puppy Linux.

As mentioned, possible difference in RAM usage is of interest.

It's also interesting what is most suitable for users with limited or no experience of Linux and possibly even limited interest in computers in general. Will it always be found in the same place? Will it end up in the menues? Can it be easily updated when AnyDesk suggests it ought to be?

Any other differences are also of interest.

Are there yet other methods?

@Kjellinux :-

It's also interesting what is most suitable for users with limited or no experience of Linux and possibly even limited interest in computers in general. Will it always be found in the same place? Will it end up in the menues? Can it be easily updated when AnyDesk suggests it ought to be?

- AFAIK, ROX-Apps are not subject to being placed in pre-determined locations by the system. They reside wherever you, personally, decide you want them to be.

- No, they don't generate Menu Entries. A Menu Entry, by its very nature, requires a fixed location for it to function. A portable application can, by its very nature, be run from absolutely anywhere; once it's being started from a Menu Entry, if you move your portable-application the Menu Entry is then "broken".

(If you would like a Menu Entry for a ROX-App, one skill that is required is that of being able to create a .desktop file in /usr/share/applications. And before you ask it, no; I don't think anyone has ever created a utility to easily generate Menu Entries for beginners. Not to the best of MY knowledge, anyway... )

- As for updating.....it's a moot point. AnyDesk have, for the last 9 months or so, been concentrating exclusively on the 64-bit version; like everybody else, 32-bit has dropped off their development "radar". That is the very last 32-bit release of AnyDesk that will ever see the light of day.....unless someone, somewhere, decides to "fork" it.

Don't shoot the messenger..!

(*shrug*)

Mike.

@Kjellinux :-

I'm thinking that if you want a screen-sharing/remote-networking type of app for a machine with limited resources, then you're going to be rather stuck for choices on a 32-bit machine. Linux has tons of command-line applications for this kind of thing, but precious few that have easily-understandable operation by a beginner to Linux.....and of those that have any kind of a GUI, most are 64-bit only now.

- TeamViewer - 64-bit only (it used to work well under Linux, but it's a PITA under Linux now it's moved to Qt5)
- AnyDesk - as stated above
- Remmina - works well, and comes as standard with many mainstream distros, but it's neither intuitive NOR easy-to-use

To my way of thinking, there's one that stands out head & shoulders above the rest for easy operation under 32-bit Linux.....because it runs in your browser. It's called

DWService

This consists of a small Python-powered app (called DWAgent) that you fire up from a Menu Entry. This sets it in motion, and then you enter a URL in your browser and do everything from there.

The DWService web-page can be found here:-

https://www.dwservice.net/en/home.html

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

I put together packages for this a while back, and wrote about it on the old Forum, here:-

https://oldforum.puppylinux.com/viewtop ... 78#1030578

The link to my G.Drive for the packages is down the bottom of the last post on that page.

Mike.

@ Kjellinux, regarding your concern about having menu entries to a movable portable rox-apps.
Don't move them.
Rox was designed to be fast and efficient. Having to start an application by clicking its menu entry isn't: you have to (1) click the start-button or Right-Click the desktop; (3) Scroll to the Sub-menu category of the application (2) having remembered where it was; (4) Slide thru other applications which may be higher up on that the application's category in order to, finally, (5) click the application’s menu entry.
Rox apps start a rox-app when you click the rox-app folder. You can drag that folder to the desktop creating a short-cut/symbolic link. To start the application just click the desktop icon: one click. Each Rox-App folder can be assigned a unique icon. Rox supports many virtual desktops and the ability to switch between them on its task-bar. If your current opened applications cover desktop icons, click an unused virtual desktop, then the application's desktop icon: 2 clicks.
But it is handy to create menu entries even if you never use a Menu. With a /usr/share/NAME-OF-APPLICATION.desktop file, a frequently used application can be assigned to a taskbar or panel icon/launcher: one click to start. Moreover, AppFinder can be added to any OS; and many desktop managers are now available which also have a "favorites" Sub-Menu to which frequently used applications can be assigned.

Although rox-apps can be located anywhere, I've found that one 'internal' folder (/opt) and one or a couple specific external folders make life easier. Those locations can be bookmarked. While Rox automatically lists each application/folder alpha-numerically, as previously mentioned, each Rox-app can be assigned a unique icon, making it even easier to spot. One external folder will usually suffice; but if you collect a lot of rox-apps (and AppImages) dividing them among "Often" "Sometimes" and "Rarely" folders may be useful.
Generally, I locate rox-apps (and AppImages) in a specific folder on /mnt/home keeping them out of the SaveFile/Folder. But if I choose to create a Puppy --using nicOS-Utility Suite's Save2SFS-- which after boot-up dismounts and no longer accesses media sources, any application I want to use [if not installed] is located in /opt. Before creating that Puppy two changes are necessary: the application on /mnt/home has to be copied to /opt, and the link to call the application has to be adjusted.
/usr/share/applications/NAME-OF-Application.desktop is used to generate a menu entry; and it’s Exec= argument specifies the binary (or binary-calling-script) which starts the application. If an application is installed that binary/script will be “on the path”: that is in some /bin or /sbin folder where Linux expects binaries to be located. Neither /opt nor /mnt/home are ‘on the path’. If they are not ‘on the path’ the Exe= argument must either provide the full path to the binary/scripts’ actual location, or to a bash-script on the path. [LibreOffice is an apparent exception. Its desktop files at /usr/share/applications are symbolic links to the actual desktop files in /opt].
Hunting thru a couple hundred desktop files in order to edit the Exec= argument of the few which are being relocated to /opt is inefficient. So for portable-applications likely to be relocated from /mnt/home to /opt the argument I supply to Exec= points to a bash script in /root/my-applications/bin: a folder ‘on the path’, unique to Puppys, convenient for locating scripts unique to Puppys.
For example, all I have to do is edit the /root/my-applications/bin/iron script from
exec /mnt/home/Pup-Apps/Iron-portable/LAUNCH "$@"
to
exec /opt/Iron-portable/LAUNCH "$@"

@mikewalsh @mikeslr

Thank you for your input and feedback. I'm sorry to say I didn't understand parts of the last reply. If this is the level in Beginners Help, I guess I will not move to Users any time soon...

I have done some more testing. I tried to install gdebi using the Puppy Package Manager. The installation was aborted du to missing packages. I followed the suggestion to update the package database and now the installation of gdebi was successful. Now the machine had also turned very slooooow, and I couldn't even get the browser up and going to download a .deb file from anydesk.com. I did a "hard shutdown" without saving and booted up again.

Next I downloaded the 32bit portable from mikewalsh's drive. After some initial attempts to open by single- or dubble clicking, I managed to unpack it using UExtract (what's the difference between UExtract and pExtract?). In the folder Anydesk-portable32.tar.gz.extracted I found the familiar AnyDesk icon. I moved it to the desktop and klicked it. AnyDesk now started successfully.

At first installation FocalPup32 idled at a RAM usage of 87MB. With AnyDesk installed the RAM usage increased to 99MB (why, there's nothing else running?). With AnyDesk up and running RAM usage went up to 108MB. A very reasonable increase. When I connected from my desktop RAM usage went up to 120MB. Still very reasonable. With abiword, Gnumeric, mtPaint and Geany open at the same time RAM usage went up to 160MB. Still very reasonable and remote control working well, even if there was a slight delay every once in a while. So far so good!

The computer was left running overnight. To my great surprise, RAM usage was now over 300MB. Why? Repeating the process, I see how the RAM usage slowly increases, one MB after another. What causes this, and how can it be prevented? When I closed down the remote support session, RAM usage immediately dropped back to 120MB again.

Working with people with limited experience and interest in computers, I have learned that if it's possible to screw things up, sooner or later someone will. For this very reason, I would like the starting point of AnyDesk to ALWAYS be in the same place, wherever that might be. It's the one thing that will make it possible for me to get connected so that I can see what's going on and hopefully offer some help. In this one particular situation, flexibility is a big royal PITA!

This is about as far as I have come with my testing. Some questions remain to be answered.

What, if anything, went wrong with the attempt to go the gdebi - .deb package route?

The portable app downloaded to ~/Downloads. UExtract extracted it to ~/Downloads/32-bit. The actual app was in ~/Downloads/32-bit/Anydesk-portable32.tar.gz.extracted. Can I remove any parts of this to "clean up"? Should all or parts of this be moved elsewhere?

What is the best and/or simplest way for me to ensure that AnyDesk is ALWAYS found in the same place?

Can the name under the AnyDesk icon be renamed from Anydesk-portable32 to just AnyDesk somehow?

I have used TeamViewer before, but since they started to try to "bully/blackmail" people into buying a license eventhough it was only used for private use (I'm still waiting for their explanation to how NO use can be commercial use...), I've switched to AnyDesk. Remmina and DWService booth look very interesting and I have put them on my list for future testing, but I see them more as Remote Desktop applications than Remote Support applications, the main distinction here being twofold. With AnyDesk I don't need any knowledge af the other computer and/or user except the nine digit number, and with AnyDesk, the remote user has full control over if and how long I get access to their computer.

@Kjellinux :-

I suspect that for you - so that every part of the Anydesk package always gets installed to precisely the same place, irrespective of Puppy - the 'portables' are NOT the way to go. What you really need is a bog-standard .pet package.

I can turn the ROX-App 'portable' into a .pet package if you like; it's simpler to do this than it is to reposition everything back into the standard file-system, and to have to re-write all the various scripts to suit.

At this present moment in time, I, personally, am convinced that for Puppy, 'portable' packages are the way to go. You however - and I can quite understand this! - are more concerned about being able to reproduce identical install results regardless of machine, Puppy OR user skill-set. So the standard .pet package is far more suitable for your particular use case.

They're not something I build many of nowadays....(*sigh*) Truth be told, I'm probably not the best person to be giving you assistance with much of this kind of thing. The inmates of my own "kennels" are so highly-customised that a raw noob, having just about managed to get his or her head around the way a vanilla Puppy install works, would be completely lost.....yet to me, it all makes perfect sense.

I feel apologies may be in order for perhaps leading you astray!

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

Give this a try:-

https://mega.nz/file/maISDZrD#CbU10BZW8 ... Po6_sh5lDE

You may get a warning about installing to /mnt/home; this is because for those running without a 'save' of any kind, /mnt/home does not in fact exist. Since you clearly have a 'save', ignore the warning & accept the install.

You'll find the MenuEntry under Menu->Network.

Mike.

@mikewalsh

mikewalsh wrote: Mon Jul 19, 2021 1:22 am

I suspect that for you - so that every part of the Anydesk package always gets installed to precisely the same place, irrespective of Puppy - the 'portables' are NOT the way to go. What you really need is a bog-standard .pet package.

For me personally, AnyDesk can end up more or less anywhere, or to be more precise, I dont need it at all for the computers I run myself. For the potential target group of my project, it's a completely different story. It doesnt't matter if it's a portable application, .deb file, .pet file or any other type, as long as it stays in the same place so it can be easily found if need for remote support should arise. Apart from that, the only other criteria would be that the choosen solution be as light on resources as possible, since this is at the core of my project.

mikewalsh wrote: Mon Jul 19, 2021 1:22 am

Give this a try:-

https://mega.nz/file/maISDZrD#CbU10BZW8 ... Po6_sh5lDE

You may get a warning about installing to /mnt/home; this is because for those running without a 'save' of any kind, /mnt/home does not in fact exist. Since you clearly have a 'save', ignore the warning & accept the install.

You'll find the MenuEntry under Menu->Network.

This worked fine. Menue entry and all. RAM usage was same as with the portable app. Unfortunately this one also "eats RAM" at a rate of about 1MB every 5 seconds during support sessions. What can be the reason for this, and how can it be remedied?

mikewalsh wrote: Mon Jul 19, 2021 1:22 am

I can turn the ROX-App 'portable' into a .pet package if you like;

Would it be any different from the .pet package that I have already installed? If not, there's no need to invent the weel again.

mikewalsh wrote: Mon Jul 19, 2021 1:22 am

I'm probably not the best person to be giving you assistance with much of this kind of thing.

I beg to differ. Your kind help has taken me forward one more step on a number of occasions!

mikewalsh wrote: Mon Jul 19, 2021 1:22 am

I feel apologies may be in order for perhaps leading you astray!

There's absolutely no reason whatsoever for any apologies! In case I was ever led astray, I'm certain I learned something new from it!

No rest for the wicked...

The AnyDesk that worked fine on FocalPup32 has now stopped working. The files are still there, the menue entry is still there, but when i klick on the menue entry, absolutely NOTHING happens. If I try to install again, it informs me it's already installed.

When I try to do the same install on Slacko Puppy 6.3.2, it installs successfully, the menue entry appears, but when I click on the menue entry, absolutely NOTHING happens.