To make a proposal for the "Shovel Ready" projects government initiative, I'm starting up a low cost ISP:
Let's see, how about...
OR ALTERNATIVELY; swap "church" for "school" and/or replace higher thought with "Bass and Drum" to make it always distinct from "Drum and Bass".
Me, Joe and Jo. This post subject to updates.
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.
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.
I vest my red drum-kit for the students to use, and my book, An Encyclopaedia.
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!
Linux Mint root partition with 1,680,820 files achieves 224,828 stat/second.
real 0m7.476s
user 0m2.893s
sys 0m5.253s
XFS Kubuntu Linux root partition with 573,884 files achieves 256,198
real 0m2.242s
user 0m0.872s
sys 0m1.581s
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.
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:
, 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:
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:
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.
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.
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.
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!
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.
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:
No daemon required prior to running - probably why Microsoft chose this format for Unity game dev app.
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, runsudo 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-downloadMore 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
}
}
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