I upgraded to 18.04 , let's see how it goes. Gouri On Thu, Apr 18, 2019, 10:52 AM Lennart Sorensen via talk <talk@gtalug.org> wrote:

On Wed, Apr 17, 2019 at 10:24:34PM -0400, Don Tai via talk wrote:

...

Did you try the Ubuntu 16.04 64 bit version?

Yeah there isn't any future in the 32 bit version and certainly no benefit to using it anymore.

-- Len Sorensen --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk

| From: Stewart C. Russell via talk <talk@gtalug.org> | One gotcha I had with Anaconda was that it usurped the system Python | interpreter[s] in the user's path. Your /usr/bin/python won't change, | but the one seen by env as a user might. Causes endless fun when | installing packages. Thanks for the warning. This relates to my lightning rumination: "what is a distro?" As a Linux user, it has been very convenient to delegate several software maintenance tasks to the distro: - selecting - security auditing - configuring - testing - bug fixing - updating I may not agree with all their choices, but it sure makes life easier. I pick a distro based on how happy I am with the distro's choices. Sometimes I install software that isn't provided by the distro. A little more work for me, but not a problem. The trouble you mention comes from software that is partially from inside the distro and partly from outside. Python3 is part of Ubuntu 16.04. But, Anaconda, part of the Python system is not part of Ubuntu. I assume you install it with pip. If you actually change how Python3 behaves (as opposed to just adding stuff), your distro's software could misbehave -- some is written in Python3. Similar problems arise with TeX (CTAN) and with Perl (CPAN) and who knows what else. Another variant of the problem arises when you need something more modern than what the distro provides. This is accute in RHEL because it is so focussed on stability. I think that Canonical's "Snaps" (and flatpak.org's "Flatpak's) are meant to address this hard problem. I don't know how well this works.

| From: o1bigtenor via talk <talk@gtalug.org> | On Fri, Apr 19, 2019 at 1:02 PM D. Hugh Redelmeier via talk | <talk@gtalug.org> wrote: | > As a Linux user, it has been very convenient to delegate several | > software maintenance tasks to the distro: | > | > - selecting | > - security auditing | > - configuring | > - testing | > - bug fixing | > - updating | | I'm not sure what you mean by 'updating'? | Are you expecting the distro to schedule the update? | Do you want the distro to inform you of newer versions? | Hmmmmmmmm - - - please? The distros I use update packages in their repo for a variety of reasons: - updated upstream (features, bug fixes, security fixes) - distro fixes (similar list) Most distros provide a tool for users to check for updates and to apply them. Sometimes they have a setting that enables the system to automatically apply any updates that are released. So: - I expect the distro to inform me of available updates - most updates will be to packages, but sometimes they are of distro version updates - I want to be able to select what to upgrade - some people might want all security updates automatically applied. Or perhaps all updates.

| From: o1bigtenor via talk <talk@gtalug.org> | I'm | finding that | there are some elements in *nix land that are insisting that because users | are so very very lax at updating their systems that the distro must itself | not only offer the updates but that said updates MUST happen. It is perhaps reasonable that that be an option. It feels wrong that it be mandatory. As a desktop user, I treat Firefox updates as urgent and mandatory. Firefox is my main exposure to Bad Guys. Some of the customers for my sysadmin services (i.e. my family) don't like updates. They are of the "if it ain't broke, don't fix it" school. And it is true that sometimes I've broken things through updates. But I still have faith regular updates are a net win. There are some parallels between vaccine and updates. | To whit - - | Canonical has moved to this system in their implementations of both | snapd and also lxd. It is possible to reduce the frequency of the upgrades | from a daily inspection and possible update/upgrade to a maximum of | a month long period without update/upgrade. Are you saying that updates are mandatory, but only for snapd and lxd? That sounds a bit odd. Is it only security updates that are mandatory? I don't use snapd and lxd. Abstractly, both need to bridge between an inside environment and an outside one. Are the updates purely to the inside, to the outside, or both? Could the updates be required to make this bridging correct? I thought that one of the goals of snapd and of container systems was the decouple versioning of inside and outside. What other purpose is there for snapd, for example? | I found out the hard way that this was a MUST from the software. Myself | I prefer to update/upgrade periodically - - - usually checking to make sure | that the software isn't going to get borked because the upgrade has flaws | in it (even more fun when the system gets borked due to flaws in the | software!!). It was suggested that it would be possible to skirt around the | constant update/upgrade cycle by using a firewall rule to hinder the forced | reach out from my system to 'mother ship'. Well that joy set up a system | that after such an update/upgrade request was blocked - - - well the system | would shut itself down. It was only after the second such incident that I | started investigating and by the fourth I could call the trend. Now I have | the issue of having directories that I am unable to remove even using rm -r | but there is a very long and definitely not simple technique whereby maybe | I will be able to purge my server of said mess. Wow. It would be interesting to know what the rationale for this is. There's a chance that the reason is reasonable. It's open source. You could rebuild it without the mandatory update feature. Or you could file a bug report. Or you could accept this loss of control. Or you could walk. | Hopefully not too much rant! Interesting to me.

...

| To whit - - | Canonical has moved to this system in their implementations of both | snapd and also lxd. It is possible to reduce the frequency of the upgrades | from a daily inspection and possible update/upgrade to a maximum of | a month long period without update/upgrade.

Are you saying that updates are mandatory, but only for snapd and lxd? That sounds a bit odd.

Is it only security updates that are mandatory?

Snapd is used to install lxd.

Do you need snapd to install lxd? Doesn't apt-get install lxd do it for you?

...

I don't use snapd and lxd. Abstractly, both need to bridge between an inside environment and an outside one. Are the updates purely to the inside, to the outside, or both? Could the updates be required to make this bridging correct?

Not sure - - - just know that snapd can be set for an update/upgrade once a month. If that doesn't happen - - - well my system (Debian 9) would shut itself down.

This led me to, umm, blink. Debian forcing updates? That is most non debian behaviour I have heard of. Some googling around led me to the conclusion that it is not Debian mandating the updates, but instead snapd. Snap is a "universal package manager" for Linux. One of its key features is, you will always be running "updated" software. I can see where it can be useful (really in container deployments, where you could be running some ancient piece of software, and leaving unpatched security holes). I don't see why it needs to be running on "managed" systems (essentially systems where you are actively administering and applying updates as needed). Do you mind me asking what the rationale was behind installing snapd? Or is it just installed by default (sort of hard to believe that Debian won't be looking to fix that mistake).

...

I thought that one of the goals of snapd and of container systems was the decouple versioning of inside and outside. What other purpose is there for snapd, for example?

My guess is that this tightly coupled behavior would make it much easier to create a fee for such connection. This then monetizes the software. Both of these 'technologies' development occur after Canonical was rumored to be contemplating an IPO.

I would not go with the conspiracy theory. There is a push towards containers, and standardization of package managers and updates is a problem that needs to be solved.

...

| I found out the hard way that this was a MUST from the software. Myself | I prefer to update/upgrade periodically - - - usually checking to make sure | that the software isn't going to get borked because the upgrade has flaws | in it (even more fun when the system gets borked due to flaws in the | software!!). It was suggested that it would be possible to skirt around the | constant update/upgrade cycle by using a firewall rule to hinder the forced | reach out from my system to 'mother ship'. Well that joy set up a system | that after such an update/upgrade request was blocked - - - well the system | would shut itself down. It was only after the second such incident that I | started investigating and by the fourth I could call the trend. Now I have | the issue of having directories that I am unable to remove even using rm -r | but there is a very long and definitely not simple technique whereby maybe | I will be able to purge my server of said mess.

Wow.

It would be interesting to know what the rationale for this is. There's a chance that the reason is reasonable.

The rationale - - - stated is to make sure that the user never has outdated software. (Implied is that users are the major issue causing software problems.) Not explained is why there is a need to run software on the bleeding edge. There just is no room left for something like Debian stable or software that is rock solid stable - - - there were a number of interesting bugs that showed up.

There are very good reasons to be running on the latest. Especially in community distros, where there isn't a full time team to analyze and backport fixes to the distro. You might not be an average user, but the average user doesn't understand how different bugs can be exploited, and if it is easy to update the package, then that is the right thing. And if something else that it depends on breaks, that software should be fixed. Most library developers I know are very careful about not breaking software that depends on them. When a breaking change does happen, it is publicised and deprecated with enough time for applications to update themselves. If they don't I don't have too much sympathy for them being broken :-). So, if you are on a community distro, and updating frequently, then this shouldn't matter to you. If you are not the average user, and do understand the risks involved, then either you are updating the library/application yourself, or paying someone to do that for you (aka enterprise distros). Now, what you are talking about is not a Debian issue. It is a snapd issue and I think most of your troubles will go away when you remove snapd

...

It's open source. You could rebuild it without the mandatory update feature. Or you could file a bug report. Or you could accept this loss of control. Or you could walk.

I don't have the skills to remove the offending part of the software. The forum topic where this was discussed was locked by the admins at least a few times as the users would be less than totally amazed and enthralled by the 'feature' and taking the dev team to task re: this gaff. I chose the last option.

This really seems like a user error to me. I don't see the need to install snapd by default. I am really interested in understanding the rationale behind installing snapd. From what I can make out, snapd should also be limited to the packages, snapd installs and manages. If canonical is recommending using snapd by default in ubuntu, then that should be corrected there. Dhaval

On Sat, Apr 20, 2019 at 11:45 AM Jamon Camisso via talk <talk@gtalug.org> wrote:

On 4/20/19 7:20 AM, o1bigtenor via talk wrote:

...

the issue of having directories that I am unable to remove even using rm -r but there is a very long and definitely not simple technique whereby maybe I will be able to purge my server of said mess.

Will apt-get remove snapd not do the trick? Also I'm curious what data you're trying to remove. Any data for snapped packages that I've needed to manipulate lives in /var/snap/ and is just plain old data.

Otherwise are you having issues with snaps themselves in /snap ? 'snap remove' is all I've ever needed there.

That was the sequence that I used. First snap remove lxd and then apt remove snapd and apt purge snapd. Looking at the directories there still were files remaining (machine isn't available right now or I'd give you the directories). I tried to use rm -r to remove the directories - - - no dice - - - - wasn't able to remove the directories. I inquired and was given a 7 or 8 step process that would be needed to remove all of the installed directories. To me this escalated the understanding that I wasn't in control of my system. Some other entity was going to tell me how I was to run my computer. As I was wanting to use the system for process control and information storage - - - well - - - that just isn't acceptable to me that the system would shut itself down because of installed software demanding updates. Regards