Linux "Q4OS"

[awake]

Aha! Snaps - yes, I do not like snaps. So far I've been able to avoid them in my Ubuntu setup. Firefox comes pre-installed as a snap, but I promptly un-install it and install it as a .deb. Much better! I agree that if Canonical pushes snaps to the point that they are unavoidable, I will look for other options. Devuan, you say ... ?

 

[Niterate]

Ta for the heads up ..

I found this particular issue when I was trying out LXD.
So - - to use LXD (a container system) you need to install snapd.
Snapd is where the forced updates were happening.

Ah .. that would be why, I remove/disable snapd, I don't like it or the 'store'.. want straight apt repo transactions, thanks very much. Hmm.. if Ubuntu does that, LXD might be a manual installation from source if needed and possible, or change tactics, and move OS base on the pi's . . . more ansilble, and learning, for me it seems

 

[Niterate]

Dare I say it @awake? ... 'snap!' *chortle*

 

[ajoeiam]

Aha! Snaps - yes, I do not like snaps. So far I've been able to avoid them in my Ubuntu setup. Firefox comes pre-installed as a snap, but I promptly un-install it and install it as a .deb. Much better! I agree that if Canonical pushes snaps to the point that they are unavoidable, I will look for other options. Devuan, you say ... ?

Devuan is a debian fork.
Baldly - - - debian moved to using only systemd as a system init (I think that's what its called - - - this is NOT my primary metier!!!!!) and a group of devs were disgruntled enough with that idea that debian was forked to allow the use of other system inits.
One major difference I'm finding - - - when I ask a question in the forum - - - at devuan - - - I most often get an answer - - - at debian - - - I've never gotten an answer.

So for me - - - Devuan from here on out.

 

[ajoeiam]

Ta for the heads up ..



Ah .. that would be why, I remove/disable snapd, I don't like it or the 'store'.. want straight apt repo transactions, thanks very much. Hmm.. if Ubuntu does that, LXD might be a manual installation from source if needed and possible, or change tactics, and move OS base on the pi's . . . more ansilble, and learning, for me it seems

Have heard of 'ansible' - - - what is it?

 

[stanstocker]

I have had good results from flatpacks, but like other do not like the snap process. Some folks tend to consider them interchangeable, but snap is a canonical only entity, only available via their "app store", for Ubuntu only. Yes, you can install snap support on other distributions, but vendor lock in is not consistent with the philosophy of open source folks. Flatpacks can be created and distributed by anyone. The nice thing about flatpacks or snap packages is the entire run time system is contained within the package. No slight differences in libraries from the one on your system vs the build version, no unresolved dependencies, and limited access at any system level. Nice from a security point of view, the entire thing runs in user space in it's own little world.

The downside is slower application start up as the flatpack creates the runtime sandbox as well as launching the app. With an SSD and a reasonable amount of ram the lag isn't horrible, but it is still slower than a normally installed app. Cura 4.8 flatpack takes between 4 and 5 seconds to launch on a machine with a ryzen 5 2600X, 16G ram, an nvmem.2 drive, and a gtx1050ti gpu running 4K. In comparison, the conventionally installed larger package Blender launches in under 2 seconds on the same machine. KDenLive video editor takes a bit over 2 seconds to launch from a flatpack. Seems OK to me, considering doing a model from 40 or 50 images using photogrammetry can run all 6/12 cores at 100 percent while cranking every available CUDA core on the GPU for hours at a time the app launch time is quite insignificant

Wow this thread has wandered from the original Q4OS topic, wonder if it should turn into a generic linux topic instead?

Cheers,
Stan

 

[stanstocker]

Have heard of 'ansible' - - - what is it?

WooHoo! And we wander the thread into ever stranger places, Who would have thought my favorite linux thread for a long time would be among my fellow metal munchers!

Ansible is 1) a superb methodology for provisioning and managing distributed systems including IOT stuff or 2) the most recent overwrought complexificated clusterized (SICx2) buzz word laden mess unleashed on the IT world. Dealers choice, here's a good starting point:

https://www.ansible.com/
I could swear the main page looks and reads just like the shiny "fact sheets" handed out at FOSE and other trade shows for the IT world back in the 1990's. Promises the same stuff too. Only difference is replacing the stock photo "two white guys and one black guy, all looking at a screen while wearing suits" with a stock photo "middle age Asian woman with a sticker covered laptop and a tattoo in a comfy chair"...

I'll skip further cynical commentary and simply say Cheers!
Stan

 

[Niterate]

Ansible is an automation tool used to configure and manage hosts (targets), mostly *nix hosts but, clients can be, Windows, Apple, BSD's, SunOS/Solaris, Cisco kit, FIrewalls, appliances, cloud nodes, typically if you can ssh to the thing, the thing (target) will likely have an ansible 'Module' to manage it's local commands, (or one being developed).. else you can just define the raw command in your config, and via the magic of shell and SSH, it will just happen.

the focus thre is 'System Agnostic' as far as possible..

Another way to think of it is like a high performance 'Terminal multiplexer' but with many more bells and whistles, like defined grouping, filtering and roles. For me it's one touch system administration .. define it once (on the master), type it once, but it happnes on 30 other boxen (targets), if you defined/grouped it that way. Think the Windows equivlelant is SCOM, if you'd like a comparitor, but far more flexible as ansible can mange windoze too.

Log into 37 boxen to run an Oracle audit script?? not anymore, define once, test it, if good, run it everywhere or by cron job at 3 in the morning.. what ever floats 'yer boat.

 

[Niterate]

yup ..

I could swear the main page looks and reads just like the shiny "fact sheets" handed out at FOSE and other trade shows for the IT world back in the 1990's

IBM Red Hat want you to buy "Ansible Tower" for megabucks.. it's their webgui for Red Hat fleet automation (adjunct to Satellite).

After 'Sponsoring' Ansbile (and to be fair throwing some $ at Ansible devlopment) which IS FOSS, they would. You do not have to buy it, if you need a GUI for ansible you could use AWX or Semaphore ... or like me at home just use the plain old terminal and cron jobs without the fancy complex resource heavy corporate GUI.

One could reflect RH was uncomfortable, and did that because SuSE Enterprise picked up and 'Sponsored' Spacewalk, the upstream project for Redhat's own Satellite product, and married that to Salt Stack autmation suite, an equivelant to 'Ansible' , (.. or Puppet, or Chef) .. just gotta be different.

It's all a bit murky, but I can happily speak to the efficacy of raw foss Ansible, and it's pretty good for my needs, which is admittedly more than the average users at times.

You can skip all the glossy Corproate hyperbole and look at the foss doco if you're keen.. it's here: User Guide — Ansible Documentation

 

[Niterate]

Actually on reflection, the best analogy for Ansible, on this particular forum is that it is "the CNC" of OS system management .. write it once, make a thousand.

 

[ajoeiam]

Only open the link - - - - first issue - - - - its Red Hat dominated - - - - as Red Hat is part of IBM's galaxy and both want to own their users - - - - oh well - - - I will look further but its already got a huge black mark on it!

Snaps are popular with the dev crowd because they only have to optimise for loading one way - - - into a snap.
Supposedly flatpak and appimage do the same thing but know appimage files are HUGE! (FreeCAD uses this option.)
Am finding these new options that promise the earth frustrating as they seem to keep finding new ways to bork up things at the same time.

Do we need a more generic thread - - - or should we break out the various different aspects of this thread into their own?
Hmmmmmm - - - do we ask the list owner for a dedicated 'linux' playpen? (LOL)

 

[awake]

You mentioned FreeCAD as an appimage - it is available that way, but also as a traditional .deb. (Maybe also as rpm??) As noted above, the appimage gives you a single consistent reference point. But in the case of FreeCAD, the appimage uses a style of icon that is unfamiliar to me - not sure if it is the Windows style of icon, or something else.

And the above illustrates some of the benefit and some of the curse of Linux and open source software - there is a tendency to make it possible to "have it your way," so we don't like it if someone locks it in so that it can only be had one way!

 

[Richard Hed]

Only open the link - - - - first issue - - - - its Red Hat dominated - - - - as Red Hat is part of IBM's galaxy and both want to own their users - - - - oh well - - - I will look further but its already got a huge black mark on it!

Snaps are popular with the dev crowd because they only have to optimise for loading one way - - - into a snap.
Supposedly flatpak and appimage do the same thing but know appimage files are HUGE! (FreeCAD uses this option.)
Am finding these new options that promise the earth frustrating as they seem to keep finding new ways to bork up things at the same time.

Do we need a more generic thread - - - or should we break out the various different aspects of this thread into their own?
Hmmmmmm - - - do we ask the list owner for a dedicated 'linux' playpen? (LOL)

No, we doesn't need a more generic thread. But what is a "snap"? A lot of terms are unfamiliar to me and so to a lot of others.

As long as no-one is whining about what someone is saying on this thread, then no need for "more general"

 

[awake]

Richard, a "snap" is more-or-less Ubuntu's version of an appimage or flatpack - a way of packaging the program together with all of its libraries. Ubuntu keeps making noises that it will transition all of its software to snaps. I understand the potential benefits (any package should "just run" without worrying about library interactions), but I don't like the speed and memory penalty ... and I haven't seen the need - .deb files and shared libraries have worked just fine for me. And if one goes this route, I'd rather they used a mechanism shared across many distros, rather than unique to just one.

I will note that Ubuntu / Canonical (the latter being the company that manages the Ubuntu distro) has made efforts to roll their own subsystem before ... and has eventually withdrawn it when there was not widespread adoption. I'm hoping that will be the fate of snaps. If not ... as I said, I guess it will be time to start looking at other distros!

 

[Richard Hed]

Richard, a "snap" is more-or-less Ubuntu's version of an appimage or flatpack - a way of packaging the program together with all of its libraries. Ubuntu keeps making noises that it will transition all of its software to snaps. I understand the potential benefits (any package should "just run" without worrying about library interactions), but I don't like the speed and memory penalty ... and I haven't seen the need - .deb files and shared libraries have worked just fine for me. And if one goes this route, I'd rather they used a mechanism shared across many distros, rather than unique to just one.

I will note that Ubuntu / Canonical (the latter being the company that manages the Ubuntu distro) has made efforts to roll their own subsystem before ... and has eventually withdrawn it when there was not widespread adoption. I'm hoping that will be the fate of snaps. If not ... as I said, I guess it will be time to start looking at other distros!

Thanx for that. So it is like an RPM that has everything pre-pakaged in one pot. I have SUSE discs from 9.2, 4 discs, in which when installing, one can choose which programs one wants and reject the rest or install them later or what ever one wants. But what you are saying is that there is no choice, you get what is in the pot and that is all and you BETTER LIKE it or else we'll call the thot, religious, and child ****ography police on you?

 

[awake]

Not exactly. Each snap represents just one program ... but any given program that you install, unless it is extremely simple, will call on multiple libraries. For example, a large number of programs that are multi-platform (running on Linux, Windows, Mac) will make use of the Qt framework, or less commonly, the wxWidget framework. Normally these libraries are installed as shared libraries, tucked away in your /usr/lib or similar folder. When you pick an rpm package, or a .deb package, it checks to see what libraries are needed, which of them are already installed, and then fetches any that need to be installed.

A snap packages up ALL of the libraries the program needs, together with the program. This means that program A, which uses Qt, has the full set of Qt libraries included in its snap; meanwhile, program B, which also uses Qt, ALSO has the full set of Qt libraries included in its snap. When you run each program, it does not share the libraries; it uses its own copy - thus, an increase in storage and RAM usage.

The good part of this is that program A might use an older version of Qt than program B. Typically, when you install these programs via rpm or .deb or such, the package manager (rpm, apt) checks to see which specific version you need, and loads that version of the libraries. Typically, it is no problem to have both Qt 4.8 and Qt 5.1 libraries installed; the naming system will keep them straight. Typically ... but sometimes there can be a collision between library versions, and that is the problem that snaps or appimages or flatpacks solve - no missing libraries, and no wrong versions of libraries, because you carry the full library with you.

 

[willray]

...So it is like an RPM that has everything pre-pakaged in one pot....But what you are saying is that there is no choice, you get what is in the pot and that is all and you BETTER LIKE it or else we'll call the thot, religious, and child ****ography police on you?

No, what he's saying is that the software houses (Canonical in the case of snaps and snapcraft) are trying to provide a framework in which "apps" on Linux can be treated like apps on your phone - just pick flappy-birds from the store and it works. No futzing with dependencies, versions, etc. If it installs, it works.

For many computer users, _this_is_great_. The vast majority of people who want a desktop computer, don't want to have to worry about which version(s) of glibc, or god help them, wxpython that they have installed. They just want the damned thing to work, just like they want their phone or toaster oven to work.

However, so long as Linux is Linux, and not just being used as some hidden microkernel, you are _never_ going to be _forced_ to use anyone's prepackaged pot. You don't like snaps? Fine, don't use them. Even if Ubuntu goes to only distributing software via snaps, who cares? Download and build the sources and dependencies yourself. There is no 'thot' police forcing you to do anything. Snaps/etc are provided as a valuable service for the people who want it.

You want choice? It's there, and it's often better than using RPMs or any other package manager - the number of times I've seen a package manager download and install, for example, the entire freakin X11 distribution just to get access to one single typedef in X.h is insane.

Is it inconvenient? I guess that depends on your definition of inconvenient. For some people, building stuff from source is inconvenient. For others, the fact that their favorite codec was left out of the ffmpeg build in the snap is inconvenient. You want the convenience of their pot, you get whatever goodies and secret sauce they decided to cook in it. You want the convenience of absolute control, get thee hence to an sh prompt and learn how to use make.

 

[Richard Hed]

No, what he's saying is that the software houses (Canonical in the case of snaps and snapcraft) are trying to provide a framework in which "apps" on Linux can be treated like apps on your phone - just pick flappy-birds from the store and it works. No futzing with dependencies, versions, etc. If it installs, it works.

For many computer users, _this_is_great_. The vast majority of people who want a desktop computer, don't want to have to worry about which version(s) of glibc, or god help them, wxpython that they have installed. They just want the damned thing to work, just like they want their phone or toaster oven to work.

However, so long as Linux is Linux, and not just being used as some hidden microkernel, you are _never_ going to be _forced_ to use anyone's prepackaged pot. You don't like snaps? Fine, don't use them. Even if Ubuntu goes to only distributing software via snaps, who cares? Download and build the sources and dependencies yourself. There is no 'thot' police forcing you to do anything. Snaps/etc are provided as a valuable service for the people who want it.

You want choice? It's there, and it's often better than using RPMs or any other package manager - the number of times I've seen a package manager download and install, for example, the entire freakin X11 distribution just to get access to one single typedef in X.h is insane.

Is it inconvenient? I guess that depends on your definition of inconvenient. For some people, building stuff from source is inconvenient. For others, the fact that their favorite codec was left out of the ffmpeg build in the snap is inconvenient. You want the convenience of their pot, you get whatever goodies and secret sauce they decided to cook in it. You want the convenience of absolute control, get thee hence to an sh prompt and learn how to use make.

Ah, thank yew for that. But you didn't say the religious and **** police won't be knocking on the door.

 

[awake]

A good point. I am somewhere in the middle - I appreciate the convenience of the apt package manager, and am happy to use it most of the time. But there are situations where I go ahead and compile from source, either to get an up-to-date version or to work around some incompatibility or so on. The latter can be a bit daunting the first time or six - figuring out all the dependencies that you need to have on hand - but with a bit of practice, it can become second nature.

I seem to recall at least one Linux distro that approaches all software installation as compile-from-source ...

 

[ajoeiam]

A good point. I am somewhere in the middle - I appreciate the convenience of the apt package manager, and am happy to use it most of the time. But there are situations where I go ahead and compile from source, either to get an up-to-date version or to work around some incompatibility or so on. The latter can be a bit daunting the first time or six - figuring out all the dependencies that you need to have on hand - but with a bit of practice, it can become second nature.

I seem to recall at least one Linux distro that approaches all software installation as compile-from-source ...

Hmmmmmmmmm - - - IIRC its gentoo where everything is compiled - - - making a tight clean system AIUI.

My issue with 'snaps' was that using them locked me into constant forced upgrades - - - you know when your machine is unusable for a while because someone else wants to futz with their ***** - - - that was the straw that broke the camel's back here!

I'm fairly much with Mr Awake - - - I don't mind compiling except I have run into programs where I was on the fifth level of dependencies when I threw in the towel. (I have been accused of running far too many programs!!!!!!!!!!!!)