TrueNAS build system will become closed source

[Alain De Vos]

So if i understand it remains free, but unclear under which license. Why be unclear ????

 

[elephant]

iXSystems and Netgate have the same problem of other parties making clones of their work. Red Hat dropped CentOS for similar reasons. If your product is mostly open source code, you're going to need some way to distinguish your product from a generic bundle of open source components.

 

[JohnK]

Pretty web interface?

Yeah, all right. I give you this.

The problem(s) start when you view that 'pretty interface' and one day it says: "WARN: googah is upside down!" and you have no idea how to fix it. A far better workflow is when you notice (on your laptop) that <widget> is not interfacing, you ssh in (to your NAS) and check the logs--because often times, 'googah' just didn't decide it needed to 'go upside down' by itself.

 

[mer]

The problem(s) start when you view that 'pretty interface' and one day it says: "WARN: googah is upside down!" and you have no idea how to fix it. A far better workflow is when you notice (on your laptop) that <widget> is not interfacing, you ssh in (to your NAS) and check the logs--because often times, 'googah' just didn't decide it needed to 'go upside down' by itself.

I'm a CLI guy from way back, no need to convince me.

 

[Espionage724]

I doesn't surprise me. Your comments are usually low in empathy.

Emotions =/= Technical; I'm kind of curious too why DIY light NAS isn't more popular over a large AIO solution (OS already provides native disk monitoring/FS tools)

vsftpd Linux and FreeBSD presents a NAS in less than 5 minutes; Samba can work too (although I'm not a fan of unicode filename stuff), and even right-clicking a drive in Windows with the Share tab works quick. I like keeping things simple

 

[JohnK]

I'm a CLI guy from way back, no need to convince me.

:] no, I'm not trying to convince you at all (I know you're mainly a CLI guy). That was directed more towards anyone else ("new" to BSD).

 

[bgavin]

Coming right down to it, I don’t need a NAS at all.

An 18tb disk in a USB enclosure is sufficient. Another one for a backup copy is nice. Both are sufficient for me. And far simpler.

 

[mer]

Coming right down to it, I don’t need a NAS at all.

An 18tb disk in a USB enclosure is sufficient. Another one for a backup copy is nice. Both are sufficient for me. And far simpler.

Network Attached Storage.
What use cases make it better than sufficient attached storage to include redundancy/safe storage?

A household with mix of systems that need to share data? Like *nix, Macs, Windows all wanting to share videos and photos? and providing a central place to back up all these systems? Almost seems like a single point of failure, but it's also a single point to monitor for data safety.
How about "SmartTVs": stream from a NAS to the display device?
NAS for data, maybe even home directories means one can update systems at will because they don't have your data.

I don't have any answers, just more questions and the knowledge that my usage has changed over the years.

 

[Maturin]

A far better workflow is when you notice (on your laptop) that <widget> is not interfacing, you ssh in (to your NAS) and check the logs

For example. Yes, of course. That's what I do.
I simply didn't want to stress all the details.

Coming right down to it, I don’t need a NAS at all.

An 18tb disk in a USB enclosure is sufficient. Another one for a backup copy is nice. Both are sufficient for me. And far simpler.

It all depends on what you need, or want, of course.

I also started many years ago with external storage drives in USB enclosures.
Depending on the amount of data you store you could find yourself in the situation playing diskjockey - switching disks, moving large amounts of data between them all night long (Those were still my Windows days. I backupped, moved, resized, copied whole partitions.)
You will not face such a situation early with two 18T drives within a common household's amount of data running FreeBSD, of course. I give you that.
But when I started on this 1T was the common size a normal person (at least me) can afford.
However,
then I bought me my first small NAS. One of those first WD "MyBooks": one HDD with a small embedded computer running some Linux, connected via ethernet to the LAN. I find the principal idea very practical: having a shared storage in the LAN accessable to anybody in the LAN.
Downside: This special thing was awfully slow. I figured out, it wasn't the LAN's bandwidth but this WD thing itself. And just by feeling I think this thing got slower with every update. It was no fun to use. And it got me on my nerves the longer I had it.
Plus, there was no chance to enlarge its space, when it would be full one day. I also don't want to go into details, but short: I simply had to buy a larger one, and then copy all data - over that annoying slow LAN port of this
Plus, there was no redundancy against hardware failure, since it contained only one single HDD. Today there are ones available containing two or even more drives, but Plus, I had no real control over that thing, no idea, what it really did, how it worked (filesystem, and other things), so no real trust in it, if it sends data somewhere...etc.
Plus, believe it or not, this small wallcube powered single HDD NAS was a real juice guzzler.

So, one day I got me an old midi tower from the attic, placed four drives into it, FreeBSD, ZFS pool, etc. - my first NAS.
Now I use the third one I built myself, and it's planned to be not my last one.
I have enough hardware redundancy, so I feel pretty safe against hardware failure. I can add capacity any time, or can move easily to another machine/pool/drive, if needed, check the services running, can control the access to it, look into log files, comfortably via ssh from my workstation, without any crappy designed for to be used by dillettants GUI within a browser, giving me limited access and limited info on very limited things presented as useless colorful graphical BS...

This does not come turn key, of course. But as I said, it's no rocketscience neither. Don't need to be a hacker to realize it. Basic knowledge on installing and configuring FreeBSD, ZFS, NFS, Samba and ssh is all you need. Just additionally with snapshots, rsync, tar, and packers, with some simple, small sh scripts and cron you can do a lot of additionally things, than just having a simple storage drive accessable over the network.
When you have the knowledge, already have the hardware (you need to get it anyway [the first set of HDDs for my first NAS I disassembled from the external USB drives I collected over the years {those are ordinary SATA drives inside} and the drives are the most cost of any NAS {many are sold without any drive at all}]), and - of course - see the need/benefits of having an own NAS, it's a weekend's job to set it up.

 

[kpedersen]

The problem(s) start when you view that 'pretty interface' and one day it says: "WARN: googah is upside down!" and you have no idea how to fix it. A far better workflow is when you notice (on your laptop) that <widget> is not interfacing, you ssh in (to your NAS) and check the logs--because often times, 'googah' just didn't decide it needed to 'go upside down' by itself.

Agreed but I also note that a compromise could almost be reached if we knew what the hell the thing was doing when we clicked a button. This was my issue with an old colleague using i.e webmin, etc. Any time he did something trivial, it would potentially munge about 5 files.

Sure, the GUI is convenient if doing routine stuff but if it also listed the exact command it was about to run or (preferably) a diff of config files, this would be useful and help resilience of when the darn googah *does* turn upside down. So few tools do this (err, list commands, not turn upside down). Actually, the last I saw doing this was probably smit/smitty from AIX!

Weirdly an issue with i.e NetworkManager and other Linux churn is that these magic commands do random stuff too. Just plain text config files are clearly going to remain the future!

 

[MMacD]

Personally, I don't know what people need TrueNAS for at all.

Nor do I. I thought it'd be a quick setup, but it turned out to be needlessly complicated instead. So after a couple of annoying hours muddling around, I scrubbed the disc and installed Apache, PHP, and MariaDB talking to a 3-way ZFS mirror. Problem solved.

 

[mer]

NetManager. I'm sorry, but simple text file that ifconfig up understands? Why do we need interface configuration in yaml?

A webased GUI may lower the entrance bar for the average residential user (face it, even the newest of newbies here are above average, even if not by much) but hinders debugging a problem. Call customer support and you get "did you reboot it, did you cycle power blah blah"
Even on products at $WORK I almost never touch the GUI/EMS because it's much easier for me to ssh, cat | grep and do all the CLI commands.

If defaults are reasonable I'm ok with using a GUI to quickly monitor status (how much red vs how much green) but often finding the correct sequence of clicks and dialogs to do complex is frustrating.

 

[sko]

The problem(s) start when you view that 'pretty interface' and one day it says: "WARN: googah is upside down!" and you have no idea how to fix it. A far better workflow is when you notice (on your laptop) that <widget> is not interfacing, you ssh in (to your NAS) and check the logs--because often times, 'googah' just didn't decide it needed to 'go upside down' by itself.

The major problem with TrueNAS, PfSense/OPNsense et al are the various abstractions and intermediate layers they usually call 'helpers' - they interfere and break pretty much all system and services configuration you want to do the proper way (i.e. using the config files).
You are forced to exclusively use the GUI, which is heavily restricted by what the web designers who wrote it actually allow you to do. Also, using a GUI is in pretty much all cases much more tedious, time consuming and inconvenient than just editing a config file.

IMHO the proper way is to use vanilla FreeBSD, configure everything either manually or via config management and then use proper monitoring (like e.g. zabbix) which can also give you some useful graphs if you need them at some point. If there's some PHB or hipster that needs some blinky graphics to look at the whole day to feel important, set up grafana to give them their useless bling (and never give them access to the actual monitoring)

 

[mer]

The major problem with TrueNAS, PfSense/OPNsense et al are the various abstractions and intermediate layers they usually call 'helpers' -

I'll speak to PfSense/OPNSense because I've used both of those: yes they have their specific ideas of how things should work, but as for interfering and breaking? I'm going to mildly disagree. What they both seem to do is gather user configuration created by the GUI, stuff it all into a single configuration file (I think both are XML) and on boot replay that over top of a default configuration done in "old style/proper way" (ie multiple config files). A lot of embedded products do something similar because it's easier to manage. System recovery is often easier/quicker because "let me back up this single file and then reapply it".

Does it interfere with someone going and manually editing config files? Yes, but the products are not really designed to be used "that way" (user going and manually editing config files).
All GUIs are more tedious than editing a config file, but if you don't know which config file and the exact syntax of that file, the GUI can prevent the user from creating an unbootable system. Yeah, not perfect, but similar "visudo" instead of "vi sudo.conf".

The visual aspect for monitoring is not a trivial thing: being able to point a browser at a device, log in and get a dashboard that is easy to understand has a lot going for it.

I'm not arguing that precanned things like pfSense/OpnSense are better than rolling your own on vanilla FreeBSD: I know because I've done both. It often boils down to time, ability and desire. Everyone can change the oil in their car, but at some point one may decide it's worth it to pay someone else to do it.

 

[Beastie7]

If FreeBSD had a more modern and predictive means of managing services (ie. SMF); there wouldn’t much need of an all-encompassing GUI layer.

 

[bakul]

Is Podman a reliable alternative to Docker containers? I have docker apps such as FreshRSS, Immich, qBitorrent etc

When I played with it, it worked fine but I haven't used it seriously. I recommend giving it a try.

 

[JohnK]

The major problem with TrueNAS, PfSense/OPNsense et al are the various abstractions and intermediate layers they usually call 'helpers' - they interfere and break pretty much all system and services configuration you want to do the proper way (i.e. using the config files).
You are forced to exclusively use the GUI, which is heavily restricted by what the web designers who wrote it actually allow you to do. Also, using a GUI is in pretty much all cases much more tedious, time consuming and inconvenient than just editing a config file.

IMHO the proper way is to use vanilla FreeBSD, configure everything either manually or via config management and then use proper monitoring (like e.g. zabbix) which can also give you some useful graphs if you need them at some point. If there's some PHB or hipster that needs some blinky graphics to look at the whole day to feel important, set up grafana to give them their useless bling (and never give them access to the actual monitoring)

I used TrueNAS when my wife and I had our first kid. I've been running BSD on servers for a while now and I was scared I wouldn't have time. When they said they were going Linux I ran away fast.

Oh, I learned the GUI is paramount the hard way. I started changing things (as you are supposed to) and my changes went away on reboot?! "dahell is going on!?". Don't get me started on that.

 

[sko]

If FreeBSD had a more modern and predictive means of managing services (ie. SMF); there wouldn’t much need of an all-encompassing GUI layer.

There's nothing simpler, more observable and debuggable than rc which is just a bunch of shell scripts.
Throw in a bunch of "echo"es and you can follow each and every step - it doesn't get any more predictive and discoverable.

SMF is a wholly different beast. You absolutely need to *learn* how to use it and leverage its features and capabilities. It's exceptionally thought through and well designed, but you really have to give in and work through the initial learning curve, then you definitely can get the feeling it might be "the last word in service management" just like ZFS ist the last word in file systems, but TBH when I was using SMF on illumos back when we had a few smartOS hosts in production, I always had that slightly panicky voice in the back of my head asking "what if this thing fails?". I've debugged my fair share of rc bugs and weird behavior over the years, and it was always a rather straightforward task (tedious, but straightforward and manageable with the most basic tools). With SMF I think I wouldn't stand a chance... I guess one would turn to sledgehammers like dtrace pretty quickly?

Sure, SMF was designed by the people that brought us ZFS and their mantra for all new code was "production safe first" - but if we take a look at OpenZFS and how this tenet was thrown out of the window as soon as the illumos/FreeBSD gatekeeping was overthrown, I really wouldn't want to use something like "OpenSMF". So for system startup and service management it's still the KISS principle all the way for me which lets me sleep well...


(No, I won't degrade myself to talk about that farce linux is using nowadays...)