TrueNAS Bloatware?

TrueNAS General
1

Maybe it is just me, I’m sure it is, but I am seeing TrueNAS feature requests to add this and that for specific use cases, that do not benefit the majority of the community, possibly. Wouldn’t this be considered bloatware?

I understand that the added items often are not huge in storage size, but it adds up.

TrueNAS is turning into significantly more than a NAS. Maybe this is the path the company wants to go, I just am unclear as to why a NAS needs to do so much Non-NAS stuff.

Maybe I’m missing some big picture, but I am old so missing things is a daily thing for me. I still don’t understand why Toyota Tundra engines are such garbage since they introduced the V6 that replaced the V8. They “say they have it fixed” and are now testing with software to determine if your engine needs to be replaced. I hope I’m not 1000 miles away from home when the engine blows.

Sorry, see, I’m old and I get off on tangents.

This is just me waking up on the wrong side of the bed today. I don’t like bloatware, whether it is running or not running.

2

We’re pretty picky about what gets taken from these requests (not everything gets in). Overall, if you look at work in 26 you’ll see a lot of effort to eliminate 3rd party dependencies and improve backend performance. I recommend taking it out for a spin if you haven’t yet.

3

I don’t think so. It’s largely a question of definitions, I guess, but “a CLI tool that’s available, but doesn’t consume any resources (other than storage) unless and until you decide to run it” isn’t bloatware in my book, particularly if that tool relates to something the OS does (e.g., nvtop when there’s express support for GPUs and their use with apps and VMs).

6 Likes
4

In most cases I agree with @dan, Shell tools that don’t take up much space and can be part of the original OS, should be fine.

However, somethings I think should be Apps. Or perhaps we need a “Shell Tools” App that contains many of the Shell tools, (that can reasonably be run from an App setting). Thus, these additional Shell tools, or even TUI / GUI tools, won’t take space on the boot drive. Adding even more Shell tools won’t be as much of a problem.

At one time Red Hat Enterprise Linux had extra tools repository. At work, (IBM, which of course had us Unix SAs use RHEL on our laptops), several tools we needed were in that extra repository, (like cluster shell).

5

+1
I think the TrueNAS GUI is too cluttered. I prefer a simple and minimalist web UI. That’s my opinion.

1 Like
6

And I’m glad that you folks do not include every request. It has to take its toll on your company as well.

I have not tried 26 yet, and I keep telling myself I will, when I get the time. Hopefully someday.

8

I get the feeling. These days what worries me more (as an individual) software-wise are supply-chain attacks. So many applications / libraries have so many nested dependencies that figuring out your exposure can be a real headache. This is one of the reasons why I like python for many purposes. The core python language (e.g. no pip installing anything) has a ton of functionality and features built into it (and is actually pretty-good performance-wise). So you can write a lot of things where your only dependency is “python”.

4 Likes
9

How about specifics, details, examples, so we can understand what kind of things look like bloatware to you.

For people with experience or deeper understanding, certain things are essential.

10

As much as I like the idea of having a lean base OS, I don’t think something like a “shell tools” app would be a clean solution. With the permissions and access to system resources and devices that many tools need having them in a docker container may make it hard to maintain that container or the apps permissions, mounts and stuff. Also I have to admit my trust in TrueNAS apps isn’t the greatest. I’ve had much more problems with running and updating TrueNAS apps than with anything else about TrueNAS in the past (not including the multiple changes in the underlying container solution).

1 Like
11

@TheColin21 you could be right.

Perhaps a different approach. Maybe a package of Shell Tools that loads in a specific home directory, thus not on the boot-device(s). And, TrueNAS knowing this, allows execute permissions on that specific home ZFS dataset.

Basically a light weight developer option. One that does not require making the boot-device file systems R/W, or modifying them.

I routinely install scripts that I run as user root in /root/bin on my computers. However, this may not be practical, (size wise, or other reason), for this Shell Tools concept. But, a path on a Data or App pool should be fine.

12

That idea sounds much better to me​:+1:t2:
But it isn’t necessary if we just accept a few MB of extra space used by these tools on the boot pool​:sweat_smile: I’m quite happy both ways.

13

I only install my softether VPN server/client code, binaries under /root.

Everything else is under a replicated dataset (user or admin).

And that’s why I have a daily cron job that does ssh to every single other server and retrieves the config files plus all /root files.

14

I tend to think of bloatware as items that are running and consuming active system resources (CPU/RAM) that have little to no benefit to core functionality. Those we should be always on the lookout for and eliminating or reducing the footprint as much as possible.

Items which are just consuming a bit of storage space on the boot device I’m a bit less worried about overall, especially if they are small and have some good reason to exist for enough users. Unless there is some security aspect we have to think about just from having them on disk, which is another discussion entirely of course.

For everything else, thats the entire point of having a robust Apps/Containers/VM subsystem, you can load whatever other functionality you want through those. Without those, we’d be really having to make hard decisions about what things to bring into the base image all the time.

8 Likes
15

I tend to agree with that assessment, but sometimes all the dependencies can get rather large. And I’m glad your team is selective in what gets added.

Thankfully Linux is a slim OS compared to Windoze.

And I was just having a bad day when I posted this thread.

16

Then the “bloatware” really is the “apps and virtualisation” part.
If it were just about pure storage, TrueNAS would be complete with the kernel, OpenZFS, middleware and a collection of drivers for all sorts of chipsets/HBAs/NICs out there (each of them indivudually being an item that only benefits the minority of users with this particular hardware and not “the majority” :wink: ).
With the expectation that TrueNAS does more than storage comes the need for even more drivers for … just about everything as well as all kind of monitoring utilities (e.g. the accepted request for the complete series of ls* utilities, I think that the request for nvtop/htop falls under the same logic).

17

An idea I have in mind is “overlays”. A small tarball, cpio archive, whatever format.

This overlay can be loaded by truenas from a certain location after verifying it and mounted ro on top of the filesystem or even under a separate directory.

That way we can have: shells overlay, nvidia driver legacy overlay, whatever overlay.

I personally needed that days ago when I moved my containers to a separate server. I wanted to get rid of jailmaker too but could not. I need it to run dovecot email sync to backup my mail on the nas. A dovecot overlay would have been nice.

I am willing to implement such functionality if IX systems would accept it.

Just my 0.02

18

I agree with @kris on the overall definition of bloatware and I also agree with @joeschmuck with the idea of bloatware is more or less anything that is unnecessary for the base task and is unused but can’t be turned off. We do not need six different variations of the same command-line program pre-installed just because someone wants their personal favorite added, or because they find the existing tools too unfamiliar.

For instance, TrueNAS already includes top and htop. Both are perfectly adequate. In fact, top is ubiquitous—you can find it on almost everything from enterprise servers to industrial controls and robotics. Like any command-line tool, it just takes a small investment of time to learn the shortcuts and syntax. TrueNAS doesn’t “need” to bundle the CLI flavor of the day. When redundant variations of the same tool are baked into the base OS, it becomes bloatware. I say this as a full-time Linux user who uses Fedora on my daily driver and only dual-boots to Windows when absolutely necessary. The biggest issue I see in the Linux world is that everyone always thinks they have a “better” way of doing the exact same task.

As for the argument of “I can’t run the specific software I want” —yes, you can.

I set up a dedicated directory on my data pool that leverages the native TrueNAS Docker system. In that space, I comfortably run KiCad, Draw.io, code-server, Backrest, and an isolated Python environment so I don’t interfere with the system’s underlying Python modules. If you need even more horsepower, you can easily spin up a full Virtual Machine if your hardware supports it.

TrueNAS does you the framework to run pretty much whatever you want, but it requires a certain level of effort to set up. Relying on TrueNAS to pre-package every single tool natively just to cater to a point-and-click workflow isn’t the solution and I think would only increase the feeling of Bloatware over time.

I agree with @kris on the overall definition of bloatware, and I also agree with @joe’s point that bloatware is anything unnecessary for the base task that remains unused but can’t be turned off. We do not need six different variations of the same command-line program pre-installed just because someone wants their personal favorite added, or because they find the existing tools too unfamiliar.

For instance, TrueNAS already includes top and htop. Both are perfectly adequate. In fact, top can be found on almost everything from enterprise servers to industrial controls and robotics. Like any command-line tool, it just takes a small investment of time to learn the shortcuts and syntax. TrueNAS doesn’t “need” to bundle the CLI flavor of the day. When redundant variations of the same tool are baked into the base OS, it becomes bloatware. I say this as a full-time Linux user who uses Fedora on my daily driver and only dual-boots to Windows when absolutely necessary. The biggest issue I see in the Linux world is that everyone always thinks they have a “better” way of doing the exact same task.

As for the argument of “I can’t run the specific software I want” —yes, you can.

I set up a dedicated directory on my data pool that leverages the native TrueNAS Docker system. In that space, I comfortably run KiCad, Draw.io, code-server, Backrest, and an isolated Python environment so I don’t interfere with the system’s underlying Python modules. If you need even more horsepower, you can easily spin up a full Virtual Machine if your hardware supports it. If you do want some “special” command line tool, then figure out what it takes and install it yourself in a container or a VM

TrueNAS provides you the framework to run pretty much whatever you want, but it requires a certain level of effort to set up as it is not a full unencumbered Linux system like Fedora is but an apliance onver top of a bad Linux system. Relying on TrueNAS to pre-package every single tool natively just to cater to a point-and-click workflow isn’t the solution, and I think doing so would only increase the feeling of bloatware over time.

19

Er… is near exact repetition your way to illustrate with a bloated post how loading different tools for the same task is bloat?

1 Like
20

I’m with you there. Good stuff. (Also I :heart: Kris’s pragmatism in curating popular tools!)

Regarding Python, I wonder if you could help me understand resistance to user-scoped venv dependencies, short of hacking the default filesystem? [NAS-130029]

More broadly (and with the exception of kernel modules), I believe these requests for userland packages are a direct consequence of unclear messaging about the system environment.

It seems to me that nearly all of this¹ could be neatly handled by the company explaining (docs), facilitating (UX), and encouraging a move to our own container-based shell environments.

There could easily be more proactive guidance (hey, try this!) and less reactive admonition (no, don’t touch that!) Modeling a tightly curated “appliance OS” in more actions and fewer words.

As you note: supply chain exposure increases the stakes. Most of us don’t need or even want to kick the castle if we aren’t lured to it; just politely show us to our own sandboxes and we’ll do our thing there, our own way.

TrueNAS has come this far being presented [at times unintentionally] as a Unix or Linux distro. If the goal is to pivot to HCI, shouldn’t we be in our own shells already?

I hope I’m saying that right. Thanks.

¹ Public feature requests and questions about apt must be just the tip of the iceberg…

21

Often bloatware has other negative effects like harvesting your data

clean code that consumes as few clock cycles & memory has serious advantages

  1. more resources for use elsewhere
  2. lets cpu put cores to sleep
  3. lets cpu down clock to use less power

In games people are seeing the advantage when code fits in the cache - AMD’s X3D CPUs with their large caches (that let large chunks of app code sit in the cache) perform at times significantly better than non X3D

To me there are questions to be asked when adding features

  1. Could this be an app - keeps it out of the core
  2. what dependencies are being setup & are these acceptable?
  3. is this a nice to have or is it critical i.e. when needed it is really needed

3 is which I put in the feature request for MemTest, as when you really need to check memory to eliminate it as a potential source of instability/errors you don’t have much of a choice