Another Ub derivative goes its own way vs Snap.

KDE Neon 221023 based on Ub 22.04 & KDE 5.26.1 departs Ub's big idea of
Snap and such as Snap Firefox.

It says:

snap list
no snaps are installed

It also says that its repo/s include the mozillateam .ppa for its Ffx
106.0.1, which repo also contains Tb 102.4 .deb.

Neon does have an operative Flatpak/flathub.

--
Mike Easter

On 24/10/2022 2:09, Mike Easter wrote:
> Another Ub derivative goes its own way vs Snap.
>
> KDE Neon 221023 based on Ub 22.04 & KDE 5.26.1 departs Ub's big idea of Snap and such as Snap Firefox.
>
> It says:
>
> snap list
> no snaps are installed
>
> It also says that its repo/s include the mozillateam .ppa for its Ffx 106.0.1, which repo also contains Tb 102.4 .deb.
>
> Neon does have an operative Flatpak/flathub.
>
>

the difference is:

$ snap list

Command 'snap' not found, but can be installed with:
sudo apt install snapd

--
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#befor

Henry Crun wrote:
> Mike Easter wrote:
>> Another Ub derivative goes its own way vs Snap.
>>
>> KDE Neon 221023 based on Ub 22.04 & KDE 5.26.1 departs Ub's big idea
>> of Snap and such as Snap Firefox.
>>
>> It says:
>>
>> snap list
>> no snaps are installed
>>
>> It also says that its repo/s include the mozillateam .ppa for its Ffx
>> 106.0.1, which repo also contains Tb 102.4 .deb.
>>
>> Neon does have an operative Flatpak/flathub.
>>
>>
>
> the difference is:
>
> $ snap list
>
> Command 'snap' not found, but can be installed with:
> sudo apt install snapd
>
Yes, you are correct; snapd is installed in the live default.

The default Discover Settings shows flatpak checked, firmware updates
only linux vendor firmware service checked, snap appears to be 'checked'
but it is not blue color check like flatpak and the KDE Neon repo/s
which are also designated default.

I'm not sure I completely understand how to interpret the Discover
settings graphical 'meaning'.

The Discover 'treatment' of options for flatpak are distinctly different
from its graphical treatment of snap, firmware updates, and kde neon
repo/s. Not only does flatpak have a function to make default and add
source, but it also has a trashcan to remove it.

I don't see a function in Discover to remove snap; so apparently
Discover handles its Snap function differently than it does its flatpak
function.

Puzzling.

--
Mike Easter

On 10/24/22 07:46, Mike Easter wrote:
> Henry Crun wrote:
>> Mike Easter wrote:
>>> Another Ub derivative goes its own way vs Snap.
>>>
>>> KDE Neon 221023 based on Ub 22.04 & KDE 5.26.1 departs Ub's big idea
>>> of Snap and such as Snap Firefox.
>>>
>>> It says:
>>>
>>> snap list
>>> no snaps are installed
>>>
>>> It also says that its repo/s include the mozillateam .ppa for its Ffx
>>> 106.0.1, which repo also contains Tb 102.4 .deb.
>>>
>>> Neon does have an operative Flatpak/flathub.
>>>
>>>
>>
>> the difference is:
>>
>> $ snap list
>>
>> Command 'snap' not found, but can be installed with:
>> sudo apt install snapd
>>
> Yes, you are correct; snapd is installed in the live default.
>
> The default Discover Settings shows flatpak checked, firmware updates
> only linux vendor firmware service checked, snap appears to be 'checked'
> but it is not blue color check like flatpak and the KDE Neon repo/s
> which are also designated default.
>
> I'm not sure I completely understand how to interpret the Discover
> settings graphical 'meaning'.
>
> The Discover 'treatment' of options for flatpak are distinctly different
> from its graphical treatment of snap, firmware updates, and kde neon
> repo/s.  Not only does flatpak have a function to make default and add
> source, but it also has a trashcan to remove it.
>
> I don't see a function in Discover to remove snap; so apparently
> Discover handles its Snap function differently than it does its flatpak
> function.
>
> Puzzling.
>
>
Sorry to hear that the updates have gotten so weird.
Don't care for the concepts in Flatpaks or in Snaps but
then after paying for yearly or bi yearly updates to Mandriva
for 5 years then to be left without help and a computer that
was very unhappy with 2011. Probably why I prefer a sturdy
Rolling Relase and am now using Linux 6.0.5 & KDE 5.26.2.
Delivered via apt-rpm via Synaptic.

The thill of a working new kernel and getting my Usenet
connection back after a glitch at the server is like
a taste of my youth.
bliss
--
bliss dash SF 4 ever at dslextreme dot com

Bobbie Sellers wrote:
> Mike Easter wrote:
>> Henry Crun wrote:
>>> Mike Easter wrote:
>>>> Another Ub derivative goes its own way vs Snap.
>>>>
>>>> KDE Neon 221023 based on Ub 22.04 & KDE 5.26.1 departs Ub's big idea
>>>> of Snap and such as Snap Firefox.
>>>>
>>>> It says:
>>>>
>>>> snap list
>>>> no snaps are installed
>>>>
>>>> It also says that its repo/s include the mozillateam .ppa for its
>>>> Ffx 106.0.1, which repo also contains Tb 102.4 .deb.
>>>>
>>>> Neon does have an operative Flatpak/flathub.
>>>
>>> the difference is:
>>>
>>> $ snap list
>>>
>>> Command 'snap' not found, but can be installed with:
>>> sudo apt install snapd
>>>
>> Yes, you are correct; snapd is installed in the live default.
>>
>> The default Discover Settings shows flatpak checked, firmware updates
>> only linux vendor firmware service checked, snap appears to be
>> 'checked' but it is not blue color check like flatpak and the KDE Neon
>> repo/s which are also designated default.
>>
>> I'm not sure I completely understand how to interpret the Discover
>> settings graphical 'meaning'.
>>
>> The Discover 'treatment' of options for flatpak are distinctly
>> different from its graphical treatment of snap, firmware updates, and
>> kde neon repo/s.  Not only does flatpak have a function to make
>> default and add source, but it also has a trashcan to remove it.
>>
>> I don't see a function in Discover to remove snap; so apparently
>> Discover handles its Snap function differently than it does its
>> flatpak function.
>>
>> Puzzling.
>>
>     Sorry to hear that the updates have gotten so weird.
>     Don't care for the concepts in Flatpaks or in Snaps but
> then after paying for yearly or bi yearly updates to Mandriva
> for 5 years then to be left without help and a computer that
> was very unhappy with 2011.  Probably why I prefer a sturdy
> Rolling Relase and am now using Linux 6.0.5 & KDE 5.26.2.
> Delivered via apt-rpm via Synaptic.
>
> The thill of a working new kernel and getting my Usenet
> connection back after a glitch at the server is like
> a taste of my youth.
>
I don't run any rolling releases as rolling; whenever I boot a 'roller'
type distro, it is always just as a live USB, so I don't have good or
bad experiences w/ rollers updating/upgrading. I do keep up w/ the
write-ups of the good and bad of rollers by such as the review Jesse
Smith did a few years ago comparing several w/ their individual tendency
to breakage or not on update/grade.

But, back to Discover as a package manager, and the management of a
'mix' of packages ranging from flatpaks to Snaps to conventional, in
this case .deb/s.

As a general rule, whenever I boot a .deb distro (or even a .rpm which
uses synaptic), my preferred package manager is synaptic, mixed in w/
sometimes my just using apt command.

Some distro/s don't even install synaptic by default, such as the
current KDE Neon, which is the OT. But, if the user 'wants' to be in
tune w/ the available packages, synaptic can't get the job done when it
comes to Snap and flatpak, not can apt, of course.

So, if one is going to have to *depend* on Discover to give a full
picture of the available packages, I believe that it is obligated to let
the user configure it in a lot of different ways, for example so that it
only shows packages which are .deb/s, if that is desired, or .deb/s +
flatpaks or .deb/s + Snaps or debs + 'everything' or whatever.

I don't think the Discover interface should be confusing or inflexible.

--
Mike Easter

Mike Easter wrote:
> But, if the user 'wants' to be in tune w/ the available packages,
> synaptic can't get the job done when it comes to Snap and flatpak, not
> can apt, of course.
>
> So, if one is going to have to *depend* on Discover to give a full
> picture of the available packages,

I learned something else about flatpak and snap in KDE Neon today.

I'm exploring an online vid tutorial about Python; which 'tutor' is
working in a Mac environment + Py3 + PyCharm. The pycharm dev/s quit
providing a current linux .ppa a LONG time ago, but they still provide
both Snap and flatpak packages, so I was 'forced' (if I wanted to use
pycharm as a tutee) to employ one of those alternate packages.

My first choice was flatpak, partly because it was a slightly newer v.
and partly because I'm 'anti-snap'; BUT... the working environment of a
live KDE Neon meant that the 'breathing room' of free storage space
(from the ram) was very low, so the flatpak which is kinda 'compily'
didn't go, it needed more room to do its thing; but the snap package
/was/ able to install, tho' compromising/using up most of the sparse
storage.

Naturally I need to make a mod to my working environment for this project.

--
Mike Easter

On 10/28/22 00:10, Mike Easter wrote:
> Mike Easter wrote:
>> But, if the user 'wants' to be in tune w/ the available packages,
>> synaptic can't get the job done when it comes to Snap and flatpak, not
>> can apt, of course.
>>
>> So, if one is going to have to *depend* on Discover to give a full
>> picture of the available packages,
>
> I learned something else about flatpak and snap in KDE Neon today.
>
> I'm exploring an online vid tutorial about Python; which 'tutor' is
> working in a Mac environment + Py3 + PyCharm.  The pycharm dev/s quit
> providing a current linux .ppa a LONG time ago, but they still provide
> both Snap and flatpak packages, so I was 'forced' (if I wanted to use
> pycharm as a tutee) to employ one of those alternate packages.
>
> My first choice was flatpak, partly because it was a slightly newer v.
> and partly because I'm 'anti-snap'; BUT...  the working environment of a
> live KDE Neon meant that the 'breathing room' of free storage space
> (from the ram) was very low, so the flatpak which is kinda 'compily'
> didn't go, it needed more room to do its thing; but the snap package
> /was/ able to install, tho' compromising/using up most of the sparse
> storage.
>
> Naturally I need to make a mod to my working environment for this project.
>
FWIW, both my KDE neon laptops have been upgraded to jammy by now.
Not fast (+/- 2 hours) but very smooth, nothing was added or removed and
apart from some small GTK glitches it looks exactly the same.
You have to re-enable your 3rd party repositories but that's about it.
I removed all of snap/flatpak/discover last year and it still isn't
needed for anything.

dillinger wrote:
> I removed all of snap/flatpak/discover last year and it still isn't
> needed for anything.

If I want to use pycharm, I will need to use an older Ub base such as
20.04 which has a .ppa for it, which is what I'm going to be working on
today. I have an older Mint around, I'll use that.

--
Mike Easter

Mike Easter wrote:
> If I want to use pycharm, I will need to use an older Ub base such as
> 20.04 which has a .ppa for it, which is what I'm going to be working on
> today.  I have an older Mint around, I'll use that.

That didn't work out either; the .ppa wouldn't take because accessing
the keyserver had an anomaly.

I went back to the snap pycharm which was easiest to install and decided
that 'I didn't like it' because it was 'too complicated' an IDE for a
complete beginner to python like me. I decided that learning about so
many pycharm features was 'distracting' me from learning about python,
so I looked around for a simpler IDE/editor and found Idle which I like
better and it is in the repo/s. Yay.

Now my python platform is live Ub 22.10 Mate + Python 3.10.8 & its Idle
same v.

Maybe after I learn some python and feel like checking out another IDE
I'll look over pycharm again, as it is popular and there is a good
learning python vid using pycharm.

So now this wandering topic has made an exit from Neon or Snap :-)

--
Mike Easter