Is this possible?

Just keep in mind that if mint updates it. you'll need to do the process again to get the updated version. Enjoy!
The manual part is what I would hate to do each time that's why I suggested it might be an idea to add the Mint repo for having it automatically updated, but if OP doesn't mind doing it manually every now and then there's no need to do it how I described.
 


The manual part is what I would hate to do each time that's why I suggested it might be an idea to add the Mint repo for having it automatically updated, but if OP doesn't mind doing it manually every now and then there's no need to do it how I described.
I understand but think add the repro from mint may cause conflicts with other packages in POPos in any event good thought. And fortunately this isn't a package that's updated often.
 
I understand but think add the repro from mint may cause conflicts with other packages in POPos in any event good thought. And fortunately this isn't a package that's updated often.
I did mention that ;)
And no guarantee that something may not break at some point because it's a Linux Mint specific repo.
 
Hello again.

Since the success of getting the Driver Manager (from Linux Mint) to work (assuming it won't break any time soon) I went and tried to install the MX Tools from that distro.

It looked like it installed from the terminal text that I saw but isn't showing up anywhere.

I thought maybe I needed to add the repository for them but that editor in the Konsole window isn't giving an option that shows "edit". So I'm a little lost on that right now.

Randy
Pop!OS...
 
MX- tools is a combination several tools and scripts. It most likely is not going to work for you on POPOS. Since it's base is Debian 13 Which is older or newer than the base that Ubuntu uses and that POPOS is built upon. you will most likely have dependency errors. I don't think it will work for you, but could be wrong. which particular tool are you looking for?
Believe that Ubuntu is base on Debian testing and Mx on Debian stable so they are really a bit apart.
 
MX- tools is a combination several tools and scripts. It most likely is not going to work for you on POPOS. Since it's base is Debian 13 Which is older or newer than the base that Ubuntu uses and that POPOS is built upon. you will most likely have dependency errors. I don't think it will work for you, but could be wrong. which particular tool are you looking for?
Hello, thanks for replying!
Actually I have no idea what any of the tools are since my test install of MX Linux bombed out for some reason that I don't remember. It was the installer or something.
But I'm happy to go with your opinion since it was just a thought and I'm not sure I need any of the tools or not.
So, you talked me right out of it!
I'm pretty happy with Pop Os right now since the kde and the timeshift and the Driver Manager installs I've got all of the stuff working that I prefer, so I'm going to call that a win for now.
 
On

ranking@pop-os:~$ sudo dpkg --install /home/ranking/Downloads/packages/ mintdrivers_1.8.8_all.deb
dpkg: error: archive '/home/ranking/Downloads/packages/' is not a regular file.

The OP had a space (unneeded) before mintdrivers, hence the error message content.

It should have been

Code:
 sudo dpkg --install /home/ranking/Downloads/packages/mintdrivers_1.8.8_all.deb
 
Hey I was just testing and saw that a newer video driver was available. So I used the Linux Mint Driver Manager to change it and rebooted. It seems to be working just fine so I made a screenshot to show the info from Neofetch and the Driver Manager to show that it had switched out the video driver.

Screenshot-neofetch-drivermanager-info.png
 
Do you have Timeshift set up and saving snapshots?

With the testing you are doing, the likelihood of things going south are increased. (experience talking there !)

A few timeshift snapshots saved to an external drive can save both your bacon and your sanity.
 
Do you have Timeshift set up and saving snapshots?

With the testing you are doing, the likelihood of things going south are increased. (experience talking there !)

A few timeshift snapshots saved to an external drive can save both your bacon and your sanity.
Yes I did install Timeshift and am using it. I think it's a very handy tool to have.

I also have the MX Tools in a folder but haven't figured out how to get the install to work for them yet.
 
A-yup. A man after my own heart...

Frankly, in spite of the many dubious - and incredulous - comments posted during the course of this thread, what you've just witnessed here, guys, is simply "business as usual" for us here in Puppyland.

We will source software literally anywhere we can find it. Stat. TBH, many of us enjoy the research / hunting around / dependency chases / whatever is needed to make stuff work for the community. Recently, one of our members unearthed a treasure-trove of specially-built AppImages.....that will run literally anywhere, on bang up-to-date distros, decades-old ones, and even stuff like Alpine Linux that doesn't use glibc at all, but makes use of musl instead. And the best bit is, these things are being currently built by a very active & enthusiastic crowd of individuals......who also offer a totally automatic update mechanism for every single AppImage into the bargain.

It's like manna from heaven for us!

Another of our members is currently working on a Puppy port of the Nix package manager, which will pull software (and dependencies) in from any distro repository you care to use...

This is one of the best things about Linux in general, and Puppy in particular. Where there's a will there is almost always a way. You soon realize there's no percentage in restricting your options.....and you very quickly learn to think "out of the box"...!


Mike. ;)
 
Last edited:
@Condobloke :-

If you're interested, Brian, the repo is here:-


Many of these appear to be game- or game-engine related, though there IS a lot of more 'normal' apps among them, too.

It's worth checking back here regularly, since this list grows daily. I can thoroughly recommend the following:-

MPV - This works brilliantly well
Gnome System Monitor - system utility
system-monitoring-center - ditto (nice, this one!)
Audacious
DeaDBeeF
OBS Studio
WebCamoid - webcam software
QElectroTech - circuit-board schematics and simulated testing (think LTSpice)
OpenTyrian2000 - nice little space-shooter game
LibreCAD
LocalSend - LAN file-sharing for your local network
Shotwell - photo-management; most people know this one!
Transmission-QT - a modern QT port of the long-established torrent client

A few I tried when we first found it seem to no longer be available, but these do definitely work ANYWHERE. The list is constantly changing, so it's worth revisiting from time to time.


Mike. ;)
 
Last edited:
It's like manna from heaven for us!

While I've only briefly dabbled in the Puppy-realm, that does sound like the dude made a great discovery. Given how you all operate, that's a pretty sweet asset. Hmm...

With it being such a broad spectrum of AppImages, maybe I should call it a 'suite asset'! :rolleyes:
 
@MikeWalsh ....Mike, Thank You !.....that is appreciated.

I have been using deadbeef for quite some time now, so I downloaded and tapped the permission to use as a program.....double clicked it and it instantly sprang to life with all my music intact....went on playing as if nothing had happened.

Excellent
 
Last edited:
and it instantly sprang to life with all my music intact....went on playing as if nothing had happened.

It probably had the sense to check for app data/config data in its usual directory -- like /home/user/.config/deadbeef.

That directory may not be accurate. It's just a guess, but that's how a lot of that stuff is saved. So, I am guessing that it's smart enough to look there and to then use that directory in the future.

If you do not want it to do that, you can tell it to use a temp folder. That'd be something like:

HOME=/path/temp/folder.<appimage_name>/app.AppImage

That should do it.
 
When it did its 'magic' , I immediately looked for the number of tracks .....the number showing was correct.

I keep 'track' of that number, (pun intended) ....there was a time when all was not well and for some unknown reason deadbeef was dropping a track here and there. I ended up reinstalling from the official page, and all has been good since then.

I like AppImages. The fact these update themselves is particularly attractive.

Yes, I have a Timeshift snapshot in place.... jic (just in case for the uninitiated)

More: I read : https://pkgforge-dev.github.io/Anylinux-AppImages/HALL-OF-FAME.html
...from top to bottom.
This is not a generic blurb turned out by ai and the likes.
This was typed out by a human.....a human I instinctively liked......speeling mistakes , grammar mistakes, a few curses, and a more than obvious penchant for the truth, regardless of how it hits the page.

Updates: A couple of messages popped up in DeadBeef......do you wish to allow auto updates etc etc in deadBeef....allowing a spot in /home for the update etc etc etc

Those messages popped up after i opened DB for the third time
 
For anyone wondering what the difference is between a standard AppImage and a AppImage.zsync
..... AI input here:

An AppImage is a portable application format for Linux that allows software to run independently of the underlying distribution, while an AppImage.zsync file is a metadata file used for updating the AppImage efficiently by only downloading the changed parts of the application. The zsync file contains checksums and other information to facilitate this incremental update process.
Wikipedia docs.appimage.org

more?

Overview of AppImage and AppImage.zsync​

AppImage and AppImage.zsync serve different purposes in the context of software distribution on Linux. Below is a comparison of their key attributes.

What is an AppImage?​

  • Definition: An AppImage is a portable application format for Linux that allows software to run independently of the underlying distribution.
  • Functionality: It packages all necessary files and libraries into a single executable file, making it easy to distribute and run applications across various Linux distributions.
  • Usage: Users can download an AppImage, make it executable, and run it without installation or dependency management.

What is an AppImage.zsync?​

  • Definition: An AppImage.zsync file is a metadata file used for updating an AppImage.
  • Functionality: It enables efficient downloads by allowing users to download only the changed parts of the application, rather than the entire file.
  • Usage: When an update is available, the AppImage can use the .zsync file to check for changes and download only the necessary updates, saving bandwidth and time.

Key Differences​

FeatureAppImageAppImage.zsync
PurposeDistributes portable applicationsFacilitates efficient updates
File TypeExecutable application fileMetadata file for update information
ContentContains application and dependenciesContains checksums and metadata for updates
Update MechanismRequires manual download of new versionsAllows incremental updates via zsync
In summary, while an AppImage is the main application file, the AppImage.zsync file is a supporting file that helps manage updates efficiently.
Wikipedia Medium
What are the advantages of using AppImages over traditional Linux package formats ?
AppImage packages are portable and don't require installation, making them easy to use across different Linux distributions. They bundle all necessary dependencies, avoiding conflicts with system libraries, and can be run directly after download.
michaelneuper.com Medium
 
That sounds like the reason. It was just using the config you already had -- which is not a bad thing, and can be started without doing that.

I like AppImages.

I don't use them much. I like my applications to be in the terminal and in the application menu. You can add AppImages to your application menu, of course. I'm just not going to do that.

That and, well, there's nothing I need that is only in AppImage format. If I needed to, I'd do so -- and I'd at least add that application to the application menu.
 
@KGIII :-

I don't use them much. I like my applications to be in the terminal and in the application menu. You can add AppImages to your application menu, of course. I'm just not going to do that.

That and, well, there's nothing I need that is only in AppImage format. If I needed to, I'd do so -- and I'd at least add that application to the application menu.
I don't use them because they're not available in any other format; usually, they are. I primarily use them because they greatly simplify the building of packages for the Puppy-portable ecosystem. There IS "method in the madness"!

I could use the standard WINE install IF I wanted to. I don't, for one simple reason.....because WINE is not the simplest thing to cleanly remove from the system. We've all seen enough folks posting on here because they've installed WINE, decided they don't want it and then find out they can't easily remove it. (That, and the fact that some Linux users seem ideologically opposed to the very thought of using WINE anyway...)

This was the idea behind the 'portable' builds of WINE. You set it all up, ready to go. You then just 'link' it into the system via a wee script, as & when you want to run a Windoze app.....and when you're done, another script just as 'cleanly' removes it.....leaving no trace that it was ever there.

(And 'clean' removal is a minefield with WINE in any case, due to the installation process creating a whole bunch of symlinks that don't get recognized - by the package manager - as being components of the original package. This is the stuff that gets 'left behind'. With the AppImages, these sym-links are all 'internal'; when the AppImage goes, they go too).

This is probably made a lot easier for us, since Puppy - at a fundamental level - uses either the 'aufs' or 'overlayfs' types of 'layering' file-system.

~~~~~~~~~~~~~~~~~~​

It's a known fact that certain Windows apps will frequently run better under particular builds of WINE than they will under others. For this reason, I, personally, use 4 or 5 different 'portable' builds of WINE.....and long ago wrote a small GUI 'switcher' utility to allow me to quickly & easily swap back & forth between those different builds.

It also enables the 'sharing' of any given WINE-portable between multiple different Puppies on the same system. Bonus! :D

Works for me, anyroad.....and makes it simple as pie when trying out newer, updated builds of WINE. I keep a 'testing' build of WINE-portable specifically for this purpose, since all you need to do is to swap the actual AppImage itself. You don't need to touch anything else.


Mike. ;)
 
Last edited:


Follow Linux.org

Members online


Top