I think my ISP will have to be a charity

Let's see, how about...

The Kotahitanga Church of Higher Thought

OR ALTERNATIVELY; swap "church" for "school" and/or replace higher thought with "Bass and Drum" to make it always distinct from "Drum and Bass".

Founders and Executive Directors / Trustees:

Me, Joe and Jo. This post subject to updates.

Mission Statement

To educate, illuminate, and inspire those in regards to all percussion and bass.
To investigate, research, publish, and promote alternative histories of cosmic biogenesis.
To involve a plant-based ecumenical religion based on Cantheism.
To fund and support our radio station WeFunk West Auckland, our bible, Tom's book series An Astonishing Encyclopaeidia, the founders various music productions, live streams, recording studio, practice rooms, lecture halls, mobile broadcast facilities, missions, pilgrimages and expeditions.

Charitable Purpose

Once per year, and ideally, as frequently as possible, to foster and enable an awards ceremony for talented young musicians, likely to involve 2 full days and up to 2 weeks of intense travel to each school in Auckland to perform at assembly and advertise the awards and to speak with the principle and head of department of music etc.

To continue to produce music CDs, streams, videos, books etc.

Founders Vestments

I vest my red drum-kit for the students to use, and my book, An Encyclopaedia.

I'm switching to XFS for my disk file systems

Silicon Graphics created XFS in 1993 to serve as the default file system for their IRIX operating system. I really don't like the way BTRFS interacts with docker, so this was the driver for my switch. That and noticing how fast it was on spinning rust HDDs. And the fact that Red Hat Enterprise Linux uses it as its default file system. That was strongly influential in my decision since it made me realise it was next-to-native on Linux, which uses ext4 by default.

Having used an SGI Indy workstation in my youth I trusted Silicon Graphics to deliver something with taste and high performance. XFS excels in the execution of parallel IO due to its design, which is based on allocation groups and enabling multiple concurrent writes. The aim: extreme scalability, bandwidth, size of files and itself able to span multiple physical storage devices. With features like delayed allocation, and online defragmentation it seems like the fastest thing about.

After a stint trying out ext4, BTRFS, and then ZFS stripes, raid z2, presently I am installing XFS everywhere at the moment. On my NVMe ext can delete a root folder at 224 kilofiles per second, but this is a very fast m.2 drive. On my slower Samsung SSD running XFS I can stat faster at 256 kilofiles per second!

Ext4

Linux Mint root partition with 1,680,820 files achieves 224,828 stat/second.

real    0m7.476s
user    0m2.893s
sys     0m5.253s

XFS

XFS Kubuntu Linux root partition with 573,884 files achieves 256,198

real    0m2.242s
user    0m0.872s
sys     0m1.581s

 

 

A review of snap, the Linux app format

I like to start a review of free software with something positive to say about the app in question, I mean it's kinda whack to complain about something you didn't even have to pay for. But the snap packaging format seems to be causing damage to the eco-system and needs a kick in the teeth and a punch in the balls.

Usually if I am writing a review at all that is because I used the software a lot and so it is really something very positive and it's usually so I can document some bug or feature that I'd love fixed. Not snapd and snaps though. Snap fucking sucks huge turds. In fact, most writing on the subject is too mild, and doesn't go far enough to explain the badness. Snap sucks shit and that's why Linux Mint decided enoughs enough.. The only reason companies like Google, JetBrains, KDE, Microsoft, Skype, Mozilla, Nextcloud and Spotify dabble with snap packages is the slight support for systemd and server apps, CLI apps, and the ease of deployment update and rollbacks... Nobody who has to use the thing wants to use it. It's not good for the end-user use, and seems to be relegating Linux desktop apps to second class citizens on their own operating system?!

Linux Mint 20 – codenamed Ulyana – will not ship with any snap packages or the snapd daemon, and will be tweaked so that the Chromium package will be "an empty package which tells you why it's empty and tells you where to look to get Chromium yourself." Further, "In Linux Mint 20, APT will forbid snapd from getting installed." APT is the standard manager for traditional Linux packages. I agree.

I'm religiously opposed to snapd

Maybe it's a marketing thing, but what appears to users to be horrific bug, appear to be considered features by the makers of Snap:

  • Enormous binary size = slow loading time
  • Firewalled disk access = makes a mess of `df` output with many mounted volumes
  • Locks down filesystem = Cognitive dissonance from not being able to access external USB drives in video editing app
  • More secure? = Webcams, audio not working!
  • Easy for developers = Crapola experience for users

, and if this is true, Canonical has made a botch job of selling the benefits of Snaps "on by default" file-socket firewall functionality. Perhaps the firewall should be off by default or some kind of wizard is run during the install of an app to show which sockets have been blocked. The fact it is closed source and a central point of authority add to the animosity.

Asciinema clip of me trying to remove snapd:

Here is an old laptop running as a surveillance camera all day taking jpegs:

╭─┐⁴proc┌┐filter┌────────────────────────────────────────────────────────┐per-core┌┐reverse┌┐tree┌┐< cpu lazy >┌─╮
│    Pid: Program:         Command:                                        Threads: User:       MemB       Cpu% ↑│
│    4081 cam2ip           cam2ip                                                14 summer       26M ⣀⢸⣿⣿⣿ 92.8 █│
│  505142 snapd            /usr/lib/snapd/snapd                                  16 root         32M ⣀⢀⣀⣀⣀  9.5  │
│  607869 btop             /snap/btop/588/usr/local/bin/btop                      3 root        4.1M ⣀⢀⣀⣀⣀  1.1  │
│  607935 kworker/u9:1-uvc                                                        1 root          0B ⣀⢀⣀⣀⣀  1.6  │
│  607823 mosh-server      mosh-server new -c 256 -s -l LANG=en_NZ.UTF-8 -l LA    1 root        5.9M ⣀⢀⣀⢀⢀  0.2  │
│    2380 cinnamon         cinnamon --replace                                    13 summer      121M ⣀⢀⣀⣀⣀  0.5  │
│  605668 kworker/u9:0-uvc                                                        1 root          0B ⣀⣀⣀⣀⣀  0.0  │
│    3863 cinnamon-screen  cinnamon-screensaver                                   4 summer       53M ⣀⢀⣀⣀⣀  0.2  │
│    1375 Xorg             /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/    4 root         45M ⣀⢀⣀⣀⣀  0.8  │
│    3787 gbr3             gbr3 /etc/xdg/update                                   3 summer       31M ⣀⢀⣀⣀⣀  0.2  │
│  519464 kworker/3:1-even                                                        1 root          0B ⣀⢀⢀⢀⡀  0.0  │
│  607050 kworker/u9:2-uvc                                                        1 root          0B ⣀⣀⣀⣀⣀  0.0  │
│  607707 systemd          /lib/systemd/systemd --user                            1 root        9.9M ⣀⣀⣀⣀⣀  0.0  │
│  552160 kworker/3:2-even                                                        1 root          0B ⣀⣀⣀⣀⣀  0.0  │
│      11 rcu_sched                                                               1 root          0B ⣀⣀⣀⡀⣀  0.2 ↓│
╰┘↑ select ↓└┘info ↵└┘terminate└┘kill└┘signals└───────────────────────────────────────────────────────────┘0/270└╯

This needs to be said because some apps are only available via snap and that aint right long-term.

 

I suppose it could be argued it might be of benefit to the user to be able to easily have some of the fine-grained permissions controls newly available to mobile users also available in their computing stack too; control of the camera and mic etc but those in my case ended up seeming like the cause of half my issues with it. It was unclear the effect of its firewall.

Snap supposedly supports:

  • reversible updates
  • only one version of app running at a time
  • some support of permissions
  • ways to lock down application permissions

Forget new users, advanced users are mostly what counts. Is this a storm in a teacut meaning, can I just uninstall snapd and then get moving with Flatpak's (which are far superior) on a distro like Kubuntu? I'm not sure, and so to be sure I have made this blog post to show that why...

Because I found that:

  • Huge CPU use seemingly constantly
  • Slow to remove apps
  • Each update to OBS Studio wiped my config folder settings
  • Number virtual folders start to appear like /snap/gnome-3-38-2004/140 and ~/snap/1234
  • various other programs appeared to have sand-boxed file-system access, in particular, a
  • My Nemo bookmarks that appear left-hand side of File Manager windows disappear from File dialogs
  • Look and Feel does not match desktop
  • Video editing app was unable to reach my external disk drive mount under /mnt
  • Some apps take 30+ seconds to launch
  • Most apps needed to have sockets opened like a firewall
  • Permissions need to be granted for things like a webcam access
  • No clear way to disable the firewall completely for the system or a specific app
  • Obominable output from `df` CLI app
  • Creates a virtual drive for each app it seems (unbelievable to be honest - this is too heavy-handed)
  • `snapd` shows up lagging reboot latencies + startup
  • Neither snaps nor Flatpak start when logging into KDE Plasma
  • Above 1% to be high usage by the way for a system either at rest or been in use for a long time, sure "it's doing an update" but no i could not see this.
  • Not sure but maybe certain keyboard commands maybe get firewalled? Need to check this. I forget which but at a guess maybe it was screen Magnifier [meta][+] ceased working (maybe was not snaps fault this may have been the GL compositor for x11/Wayland in KDE Plasma somehow being disabled)
  • Terminal command used to launch an app changes
  • Normally to run /usr/bin/obs I can just type 'obs' in terminal to launch, now I have no idea

So I switchewd to Linux Mint - which is fantastic except because it comes without snapd pre-installed.  But now I want to run Kubuntu to get KDE Plasma direct. Not installed on top of  XFCE as is the case presently on Linux Mint XFCE. I'm about to try a system refresh based on Kubuntu and will be ripping snapd out post install, hence wrote this blog.

Configuration

Unix has this very cool way of doing it's file-system. An app can always access the users home folder with tilde ~ and many store there preferences in ~/.config.

It was fairly good, but you neglected to mention that with snap I end up with ~/snap which ends up looking a lot like ~/.config but much more complex. For the directly installed 3D app Blender it's got it's config just in ~/.config/ and I can see I've used it in 2 versions, v2.82 and v3.0. This makes sense, and the app launches in under 1 second on my beastly machine. I can start it with just blender as it's located at /usr/sbin/blender. But with snap rather than launch the app I launch snap with blender as a parameter? Looking in ~/snap/blender/ is another story. This has 5 folders but none seem relevant to Blender.They are: 65, 168, 624, common and current symlink, which is pointing at the 624 folder. I guess these are versions of the snap build. All three are empty. I guess I never ran the snap version. I spent a lot of wasted time configuring OBS Studio as a snap until I realised it runs way way quicker on bare metal. And my settings were not persisting through upgrades.

File Load and Save Dialogs

This was the last straw that did break my camels back.

The snapd component is written primarily in C and Golang whereas the Snapcraft framework is built using Python.  snapd has proprietary code from Canonical for its server-side operations with just the client side being published under the GPL license.

Alternatives to Snap

Snap is Written in Go, C, Shell script, Python, JavaScript, NASL, but the source is not fully available. Ubuntu and its official derivatives pre-install Snap by default, as well as other Ubuntu-based distributions such as KDE Neon, Solus, and Zorin OS. While other official Ubuntu derivatives such as Kubuntu, Xubuntu, and Ubuntu MATE have also shipped with the competing Flatpak as a compliment, Canonical will prohibit them from doing so beginning with Ubuntu 23.04, meaning that it must be installed manually by the user!

Flatpak

Over winner with a balanced use of shared libraries, balanced level of deep integration with desktop (it's like a statically compiled binary, so works brilliantly, no loss in performance through virtualization). The use of "runtimes" enables shared libraries like Java, Node, Python, dotnet etc to be used efficiently, yet also allows developer to package beta or cutting edge copy of a library if desired.

AppImage

It's predecessor was created in 2004 by Simon Peter according to this OS Technix site.  Boiling it all down, I would say the stand out features of AppImage are:

  • Unique but rarely beneficial ability to run multiple versions of the same program simultaneously
  • One app - one file. All needed files are included in the one archive, like a True Rasta. One Love.
  • Downsides: is a huge file, does not use shared libraries well, does not received upgrades from system
  • Same fast performance as Flatpak. Reliable static compile (as are all 3 packaging formats to be honest)

No daemon required prior to running - probably why Microsoft chose this format for Unity game dev app.

How is snap running under Manjaro?

So I did another full re-install of my os. I think the stated reason this time was.... a desire to get away from BTRFS file-system. If du and qdirstat

An Example Of The General Vibe Of Snap

Take for example, the following guidance getting MS dotnet SDK up on Linux in relation to Snap:

Special instructions - Linux Snap instructions
The Linux Snap packages for the .NET Core SDK, by default, will not create the dotnet link. To do so, run sudo snap alias dotnet-sdk.dotnet dotnet. More information about this can be found in the .NET Core SDK release notes. Note that, as of the time of this writing, there are also other incompatibilities between this extension and the .NET Core SDK Snap package beyond the dotnet PATH issue. This incompatibility may result in: Some projects have trouble loading. Please review the output for more details. It was not possible to find any installed .NET Core SDKs Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from: https://aka.ms/dotnet-download

More information about this problem can be found in dotnet/cli#12110.

Some community members have been successful in using the Snap install by following the instructions listed in Configuring Snap installs of dotnet-sdk. Another possible workaround is to add the following to ~/.omnisharp/omnisharp.json.

{
  "MSBuild": {
  "UseLegacySdkResolver": true
  }
}

Examples From The Net Of Weird Issues With Snap

jason-persson commented Apr 8, 2022. I have the same issue. I tried using the snap package of the sdk instead, but this segfaults when doing a dotnet restore. I'm not sure why the snap segfaults considering snap packages are meant to be self contained.  see: https://github.com/dotnet/sdk/issues/24759