@dan yeah I didn’t think about the OS part, considering Linux is far more popular than all the true Unix derivatives combined. I was just thinking about it more from a publicity standpoint, which doesn’t really make much difference either, not exactly sure why I said that lol
Regarding “why is everything about docker?!”, I think it’s largely because most people (enterprise and home users alike) don’t really want K3S/K8S on TrueNAS. If they’re going to use Kubernetes in some form, they probably already have clusters set up with Rancher or the like and just want to use TrueNAS for storage, and have a box based on Linux instead of FreeBSD. The Home users are the most vocal because we want an easy to use “all in one solution” like OMV and unRAID have. We don’t have multiple servers (well, most of us haha) to run a storage box and a Kubernetes box, or don’t want to deal with the headaches of running both in a VM on a hypervisor like Proxmox or VMware and suffering the loss of performance. The enterprise users likely just forgo even setting it up and use what they already have in place, then just share the datasets out via iSCSI, Fiber Channel or NFS. They don’t complain because it doesn’t really effect them.
Also, the switch from BSD to Linux wasn’t entirely about app support, but that was definitely a big selling point. Another huge benefit was being able to run VMs under a high quality and well tested hypervisor (KVM instead of Bhyve). There are also many other benefits which are less “flashy”.
Removing TrueNAS’ apps catalogue and just releasing two simple plugins like @etorix stated wouldn’t be removing app support, it would just take away the burden from the TrueNAS dev team, allowing them to focus more on what they’re good at and known for: storage and a great GUI. I personally think it’s a great idea as well. Provide the user with like two or three options: a RancherOS VM image that can be setup in one go without any Middleware taking over control and then a plugin/script to setup Jailmaker with Portainer and Dockge without any Middleware interference. Routing all this stuff through a middleware just makes it unnecessarily complex IMO and leads to odd issues, as mentioned in the TrueCharts setup guide. Let the user have control and stop holding APIs hostage!
Yes, it would. “Paste in and edit a docker-compose file” isn’t app support, and none of the major (or even minor) NAS software treats it that way[1]. “App support,” as it was advertised for SCALE, and as it was previously advertised for CORE in the form of plugins, and previously yet for FreeNAS also in the form of plugins, is point-and-click to install the apps, with edits to minor parameters like the app name. To remove that in favor of “point and click to install Portainer” would be a huge step backward in terms of functionality, and would erase a major part of SCALE’s reason for existing, when another major part of that reason has already been erased with the death of Gluster.
I don’t think most people who are using the apps care about the backend technology; they just want them to work. It’d probably be good for them to learn a thing or two about that backend technology so they can better troubleshoot it when there are problems, but they shouldn’t need to know anything about it in order to use it.
If you don’t want prepackaged apps and just want something to manage docker-compose stacks, great–every version of FreeNAS since 9.10, every version of CORE since 12.0, and ever version of SCALE ever, has provided that in the form of “run a Linux VM and put whatever you want on it.” SCALE 24.04 adds to that another way to deal with that in the form of sandboxes–though I think it’s weird to treat them as though they’re all about Docker. If that’s what you want, great–but that’s not the headline feature iX have been advertising since they announced SCALE.
iX has believed for the past 15 years–as long as they’ve had any involvement with this product–that a significant portion[2] of their user base and/or target market wanted plugins. I infer that from the fact that they added them into 8.0 and have advertised them ever since. They never worked well[3] under FreeBSD, but they were there and heavily (misleadingly, IMO) advertised. With SCALE, they’ve been even more heavily advertised, but the difference is that they actually work.
To give several examples: Synology’s DSM, QNAP, the as-yet-unreleased UGOS, unRAID, OMV, and XigmaNAS, all provide a point-and-click method to install other software, under a variety of names. Some of them do provide direct Docker access and some don’t, but none of them consider that to constitute providing plugins/extensions/apps/whatever they called them. ↩︎
And hypothetically, if Sandbox based Plugins/Apps were a thing… ie “point and click”, then a “Dockge” app with a host path for the stacks would get you a proper docker-compose “app” too. with GUI… or with a shell, or with low level access to the compose yaml files.
Thing is, if you start trying to think about how you would make a point and click app ecosystem… then you end up back at k8s.
heh.
because k8s gets you full definition of networking, volumes, workloads etc, via editable text configs.
OR you hack something on top of docker/docker-compose. which I guess is what most of those other NAS things do.
It would be dead simple for them to include the compose file since it’s literally just a text file, and how is editing a compose file different than editing mount points for the built in K3S support? The only difference is that the latter is obfuscated behind a GUI, which they could definitely do for the compose file with something as simple as sed/regex . IMO “app support” means you can run apps on the system with minimal changes. It’s like how Proxmox supports ZFS, but you have to manage it via the CLI instead of the GUI. Obviously doing something like Jailmanager isn’t officially supported, but as @stux showed in his great tutorial it’s definitely possible and won’t get wrecked after an update (I’m assuming, since he didn’t have it installed in his rpool).
Would it really though? It seems a fair amount of us are having a bunch of headaches with the current implementation. I’m no novice when it comes to TrueNAS or Linux (I know a bit about K8S since we used it at work, but that was via Rancher [about 100x better than IX’s support for K3s/K8s if you’ve never used it] one guy on our team was the lead on it and usually did most of the stuff). Setting up the Docker engine in a Linux jail and doing “docker compose up -d” and bringing up multiple containers is far easier IMO than configuring each container individually though a UI, especially if something like Dockge is integrated (Portainer sucks with Docker Compose, it’s kinda baffling how they never really integrated it like Dockge does). There comes a point when doing everything though a UI just becomes cumbersome and doing it via the CLI (or submitting commands to the CLI on the user’s behalf) is far easier. Like I stated in one of my previous posts, assuming I have all my container data available from a previous setup, I can bring up about 35 containers routed via Caddy as my reverse proxy and secured with SSL in under 5 minutes. Trying to set up all the apps I have in K3S would take at least an hour or two, even if I had all the config data backed up because I would have to search for the app, install it, and fill out the form data for it, not to mention the cert configuration. Granted it has taken me days to write and perfect all my compose files, but you only have to do it once,
I think it’s pretty obvious we do, and if you can’t see that you have your head in the sand, buddy. You even said it yourself with your “why is everything suddenly about Docker?” (paraphrased) comment. I think it’s pretty clear that most of us would rather have Docker support rather than Kubernetes support. IMO, the only reason why IX went with K3S instead of Docker is because they were focusing on enterprise usage instead of home usage, considering that’s what makes them money. I’d love to see a breakdown/statistical analysis of TrueNAS SCALE customers that actually use the K3S implementation in an enterprise production environment. I worked for Major League Baseball/Disney+ for 5 years and they never even considered using something like TrueNAS, suggesting something like that was literally laughed at. We only used ZFS on our ancient encoders for MLB live data (I’m not saying that ZFS is “old hat” because it definitely isn’t, CERN uses it for the LHC), and they were SPARC systems running Solaris 5…in 2023. Everything else was using Dell EMC servers and I forget what we were originally using since I wasn’t on the Storage team (and I haven’t worked there for a year), but we later converted pretty much everything over to using MinIO, we signed a multi-million dollar deal with them. Not to shit on IX or TrueNAS, but I think they’re a small fish in a big pond when it comes to storage. If you’re a Linux based company, you’re probably not going to even consider using ZFS since it’s out of kernel, unless you’re generating tens or hundreds of PBs frequently like CERN is, and they’re probably using one of the BSDs or Solaris anyway. IDK how much we had at Disney Streaming Services (Disney+) but it was definitely in the tens of Petabytes. Just across the street from me in our DC in Manhattan we easily had at least 1-2 PBs, and we had at least 7 major DCs across the world hosting major infrastructure, with multiple others just acting as CDNs.
The problem with that approach, as I’ve stated earlier, is that Bhyve pales in comparison to KVM. It’s like comparing a 1992 Honda with a 2024 Lamborghini. Bhyve just flat out sucks, I attempted that approach and my VM would regularly crash about every 48 hours using a Xeon 2011-V3 (yeah, it’s an old processor but still pretty beefy), I haven’t tried a Bhyve VM with my current Threadripper 2790WX…because why would I after my terrible experiences with the Xeon? Apparently the devs were running the same processor, but running TrueNAS via a hypervisor and coudn’t replicate the issue. I had no issues running a VM via KVM though, so it wasn’t a hardware issue. KVM started development in 2006 and Bhyve started development in 2011, I don’t think I need to tell you which one received more attention. I attempted to setup everything in as Arch Linux under SCALE and when I increased the cores from 1 to 30 (my Threadripper has 24 cores/48 threads) and the memory to 32 GB ( I have 128 GB), it pegged all cores at 100% while downloading “stuff” via NZBget to one of my ZVOLs which was on an NVME drive. It seemed that the massive amount of data being written was bogging down the VM, even though I used the VirtIO driver, NFS definitely has worse performance IMO, I’ve used it many times before, and it’s like a 5th of direct access no matter how much you tune it.
Beliefs are often misguided, history has told us such. Like I said earlier, this was most likely a focus on Return of Investment aka IX spent time developing the K3s infrastructure and believed that they could sell it to enterprise CORE customers (or new customers not wanting to use CORE), they didn’t care about the home user because we didn’t generate revenue. IX may be open source, but they are a business first, and if they didn’t make money they would fail. You can’t honestly tell me that they “focused on plugins” in CORE. The last time I used it there were like 20 available and they’re (of course) all setup in FreeBSD jails using packages that are pretty far behind upstream (maybe I’m just used to this since I’ve been running Arch for over a decade, I know Debian tends to lag far behind most distros as well). Literally your only option to get updated packages was to create a base FreeBSD jail and then install the packages from the Ports Collection, which compiles everything from source and would often leave me in dependency hell for hours on end just for one app.
Once again, I feel that their decision was driven by Return On Investment, CORE apps suck, we pretty much all know that. SCALE was proposed as a “fix” to the suckyness of the CORE apps and while it does work, it’s not exactly the best option. Like I said before, it’s extremely cumbersome to set up a lot of pods/containers. It literally takes hours even if you already have the app data, since Kubernetes defaults to storing everything in a volume of shared storage instead of locally. The distributed nature is what makes Kubernetes awesome, if you only have one node it kinda defeats the purpose IMO. The benefit of Helm Charts and Docker Compose is the fact that you can define everything the app (or multiple apps) needs at runtime, no arduous filling in web forms for every property to get the stack/pod to launch. I feel this is the point that they MASSIVELY faltered on, they took something that had been progressing for years and essentially brought it back to the beginning.
Did you happen to be active in marketing? Good suada. Though …
You base here on some assumptions that not everyone has to share. E.g. bhyve and FreeBSD are working. Maybe not for you or Disney+ (had to laugh about this one) or iX or in principle to cross the Sahara, but transaction authentication for European e-payment (credit cards incl.) is no homelab installation. Strange. Running 24/7 365.
In any case, I find it unnecessary (to even misleading) to infer the value or importance of a product from one decision in a company. It may say more about the decision-makers and their preferences than about the product.
The same applies to the assumption that this or that implementation is better placed in the GUI or in the shell. That depends on the user.
Whenever someone comes up with the supposedly universal solution, I can no longer take all subsequent advice seriously. Without explanation of what something should be the solution for, what restrictions it is subject to, etc., much is at most half-true.
In general: It would be enough for me if people were given the choice.
Maybe it’s because I’m a bit drunk off the Irish Whiskey I’ve been drinking and the fact that it’s 3 AM, but I don’t really get your point. Of course home users aren’t going to run European E-Payment software…but are Europeans even using TrueNAS for that? As for my reference to my previous job, it just goes to show how little marketshare TrueNAS has in the enterprise sector for massive companies. I’m sure smaller companies use it without issue, but even a hundred smaller companies doesn’t even come close to the “Big Dawgs” like Disney+, Netflix, Amazon Prime and others. After all, isn’t the focus of a company to make money? OSS isn’t purely about altruism, sometimes it’s a necessity due to the GNU/GPL. This is exactly the reason why Apple chose BSD as the base for their Darwin kernel instead of Linux.
All I’m pushing for is exactly that option, but not from a business standpoint. Your reply seems entirely focused on the enterprise sector, I have zero statistics on the amount of enterprise customers vs free users, but I’d imagine that the latter has a larger userbase, simply because who doesn’t like free stuff? If you’re an enterprise user you’re not going to drop 5 grand on a single controller per year (according to a quick search of “truenas cost”) until you test out the free version first. If it’s a PITA, why would you consider dropping thousands of dollars on it and not go for something else? Granted MinIO is FOURTY EIGHT THOUSAND PER YEAR for 200 TiB of enterprise support, it has a much better reputation than TrueNAS with ZFS. There’s a reason why ZFS isn’t the preference for block and object storage, not that that’s the fault of IX, that’s entirely up to Linus and his team, but Linux and ZFS are about a good mix as Peanut Butter and Honey, compared to Peanut Butter and Jelly (maybe that wasn’t a good analogy, it’s currently 3:30 AM and I’m still drinking haha, just trying to imply that one is better than the other, PB and honey is great, but not the standard).
Exactly our point! Why force K3S on home users when we don’t need it? It just creates unnecessary headaches. I don’t need redundancy and scaling for my Sonarr/Radarr/NZBget/Plex/etc… pods/containers so why should I be forced into that paradigm? I’m perfectly comfortable operating in the CLI, it’s my primary mode of operation, as I assume it is with most Linux SysAdmins/Engineers/Architects but in TrueNAS that’s sacrilege unless you use their custom built shell…which takes learning in and of itself, why force the user to learn something else new? Give them access to what they know! Guaranteed they know how to manage everything via bash or whatever standard shell they prefer. TrueNAS literally forces you to use their GUI (or their shell) or everything will go to hell, they pretty much tell you that from the start. Granted this isn’t specific to TrueNAS, it’s just a huge annoyance when you know what you’re doing. It’s kind of like the Apple or Microsoft mentality of “You’re too dumb to do this manually, so let me help you through it”. There is ZERO way to automate deployments in SCALE, using Ansible or Puppet in SCALE would be something I wouldn’t wish on my worst enemy, granted Ansible is easier since it only relies on SSH, but shelling into TrueNAS itself and expecting it do things via Bash isn’t the way things work here. If you know anything about CI/CD (not saying you don’t, maybe you’re not currently thinking about that) you’d know that automated deployments are essentially king in a large environments.
Of course there is no “universal solution” which is exactly why were a huge advocator for the inclusion of Docker. Kubernetes doesn’t cover all userbases, so why assume it does? IX is pretty much taking the standpoint that Kubernetes is the universal solution when it clearly isn’t.
Maybe it’s the whisky over here. I just tried to make the point that “microservices” with bhyve and jails running on vanilla FreeBSD as the base infrastructure work exceptionally well. And you are absolutely right: TrueNAS is not part of that e-payment infrastructure. But ZFS is.
Regarding the OSS part (and especially the Darwin/Apple example): I don’t think there’s much to be proud of. I don’t think the “well, it’s business” excuse is acceptable per se. It’s just “(part of the) source available” while “enhancing” it to the point where it’s incompatible with free alternatives. (Just like companies like MongoDB, Cockroach Labs, Confluent, Elasticsearch, etc.) Fork it … b0rk it.
That’s NOT what OSS is about. IMO it’s more about: “Who taught you to read and write? How much did you pay for it? Who gave you those compilers? Who gave you that hardware on campus?”
So I really liked the TN “way”: Product for free, because we took it for free. Money for hardware, support, coaching and special extensions. But now, if you adapt to “the market” where $OTHERPROJECTS set bad examples, it could end up with peanut butter and honey. (Just to adapt …)
Regarding Linus … you don’t have to worship the things he does/decides, but he has got reasons. (Good reasons in my eyes.) Because he puts freedom before technical progress. I like that. (Even though I agree, that it’s harder to integrate ZOL at the moment …)
Every maker of NAS software I can think of thinks they need to include app support[1]. None of them thinks that “paste in a docker-compose file” meets that need. Some of them provide that as an option, but none of them have it as the only option. Could they all be wrong about what the market calls for? Sure, but it doesn’t seem very likely–but maybe you know better than all of them put together.
Yes, it really would. Can you really not understand the difference here?
And in case this hasn’t been clear: I’m not in any way making a value judgment. I’m not trying to argue for the superiority of a managed apps catalog, nor for the inferiority of something like Dockge (which I also use). What I am saying–and I’m honestly baffled that you’re disputing–is that they aren’t the same thing.
You think you represent “most people who are using the apps”? I don’t think you do. I think you’re generalizing your own desires and objectives to larger portions of the population than I believe they represent. But unless either of us has statistics on the question (and I know I don’t), we’re both just guessing here.
But a somewhat-relevant metric would be to look at the threads in the Apps and Virtualization category. How many of them deal with “how do I get this docker-compose stack working,” and how many of them deal with “how do I get this app out of one of the catalogs working”? I think you’ll find that the latter far outnumber the former.
And it’s somewhat similar with respect to the sandboxes now available. Nothing in the forum threads requesting them was talking about Docker. Nothing in the Jira tickets was talking about Docker. Nothing in the posts from iX discussing the feature was talking about Docker. But now it’s released, and suddenly we’re in this parallel universe where sandboxes are all about being able to use Docker–rather than what they were requested as, discussed as, and released as, which was as a Linux equivalent/parallel to a FreeBSD jail where you could run pretty much whatever you want, including but not limited to Docker.
Obviously there are some people, you among them, who just want to be able to do your thing with Docker. But I submit that not only do you not represent the majority, you in fact represent only a small minority.
That you’ve stated it doesn’t make it correct in any relevant way[2]; plenty of users (hi, @pmh) have reported that bhyve works very well as a hypervisor for Linux guests. That’s been my experience as well, though with very minimal usage on my part.
But leaving that aside, SCALE’s been out for a little over two years. It’s always had KVM. So however awful bhyve may or may not be, you’ve had a mechanism to do whatever you want with Docker Compose on SCALE for 2+ years. Dragonfish introduces another way to do it.
Of course they are. Are you saying that iX’ belief that they needed to provide plugins was? Because if so, it wasn’t just they who were wrong, it was (and continues to be, 15 years later) everyone–every significant provider of NAS software, commercial or F/OSS, has a plugin ecosystem, and none of them thinks that “paste in a docker-compose file” suffices. That can only mean that they all believe their customers/users want it. If anything, iX was kind of late to the party in this regard. And no, iX never did it well (until SCALE)–but they still put effort into developing two distinct plugins frameworks for FreeNAS (one using .PBIs which came in with 8.0; the other using iocage that came in around 11.1). This takes time and staff effort, which costs money when it’s a company behind the product. Synology has done the same. So has QNAP. So has whoever’s developing the OS for Ugreen. So have OMV, unRAID, and even XigmaNAS. They all see enough of a need here to devote a significant amount of time and effort to meeting it, a need that you’re marginalizing[3]. Are you really going to take the position that they’re all wrong?
How do I know they think this? Because they do include it, and it’s obvious from looking at their products that they put a good amount of effort into it. ↩︎
“KVM works better with Windows guests,” for example, wouldn’t be a relevant way in which KVM is better for purposes of this discussion ↩︎
I’ve grown to loathe this word, but I do think it’s appropriate here. ↩︎
Fundamentally, the reason I jumped to scale is because I’d been dealing with Bhyve instability since TrueNAS 13.
My big docker vm would hang sporadically.
Last straw was I set up a jellyfin docker on another system that had been stable and as soon as the transcode started…. Hang. Same issue i had in the other.
It’s a BSD Bhyve bug. It’s fixed in 14 apparently.
So, I gave up on waiting, and have not had a single stability issue since jumping to Cobia (and now Dragonfish)
And now I’ve been able to replace the VMs with sandboxes. (Still working on replacing the big docker vm, but it has been 100% stable since migrating to scale)
Jails were and continue to be just fine, so long as the software in question runs on FreeBSD[1] and you’re fine installing it manually[2]. Plugins, as you know quite well, aren’t and never have been “just fine” or “good enough.”
I started learning docker, kubernetes, Linux etc before I even knew what a jail was. I remember trying to decide how to deploy nextcloud, whether as a plug-in, or using this script
Once I learned BSD and jails, I’m now leaning towards “if you can’t run it on BSD, you don’t need it (kidding, I realize the need for diversity)
I’ve used both CORE and SCALE and because of what I already know, I’m sticking with CORE. SCALE for me has been that (OP) on and off, trying each new release, finding CORE still my choice.
Personally I’m considering trying a migration from OMV5 (it’s pretty outdated) to Scale. This is for my mom’s NAS I built for her that I added the ZFS module to and have been hack-jobbing management that way (ZFS because I’m cross-replicating between our houses. ). She’s actually not using any of the OMV features at all, operating entirely out of the NextCloud instance I fumbled up using Docker.
It sounds like it definitely won’t be a 1-to-1 transition, especially with how Docker fscked up the pool with how it does images, but I have high hopes I can achieve a migration plan on a scrap test machine before making the trek over and do it on the live machine.
Maybe they’ve improved it quite a bit over the years. The last time I used CORE was back when 11 first came out. I never had an issue with Jails, it was just the limit availability of apps I wanted. I’m not sure why you brought up the e-payment infrastructure if they don’t use TrueNAS, it’s just about as relevant as CERN using ZFS, but not TrueNAS.
Yeah, I guess it wasn’t clear, but I was talking negatively about Apple, stating they they chose BSD instead of Linux because they could profit from it without sharing most of their work. I agree that it’s a crappy attitude and this was what I mean I said “they do it because they have to”. I guess maybe a better example would have been the relationship between Microsoft and Linux.
I agree as well, he does good work, he created Linux so he should have a huge say in it.
Of course, because a NAS is no longer just “Network Attached Storage” they’re all customized server OSes. When did I ever say that docker-compose needs to be the only option? You’re the one that seems to be 100% anti-Docker, I’m not anti-Kubernetes, I just think it’s a bit cumbersome for a lot of free users to benefit from. All I’m saying is give the user the option, because currently Kubernetes is the only supported option (going based on your definition of “supported”). You’re referencing all the other NAS/server OSes that home users/SOHO users use…and how many of them have Kubernetes as the primary option? None that I’m aware of, please let me know if I’m wrong (honestly). I never claimed that I was right, I’m just voicing my opinion.
Of course they aren’t, one is a lot simpler solution. We can debate until we’re blue in the face about what “support” means, but integrating an already well known solution (Portainer and/or Dockge) that tons of people are already familiar with (or can easily learn in a few minutes) instead of reinventing the wheel is arguably easier. It means IX doesn’t have to spend time integrating every little feature into their UI so they can focus on the storage side of the OS and users don’t have to feel limited to only the containers provided/supported by IX and those features exposed by the UI. Most popular containers already provide compose files and, as I’m sure you’re aware of Dockge can convert simple docker run commands to compose files. I guess I’m the only one that considers copying and pasting, then editing a few strings easier than clicking through a few things and filling in multiple different fields.
Of course those that are unhappy with the current solutions provided are the most vocal, so there may be a bunch of people who are happy with it, who knows for sure.
…of course you’re not going to see posts for something that isn’t “supported”, it’s like going to an Windows forum and expecting to see tons of posts asking about how to get Linux apps working. Why would anyone expect it to be any different?
There’s TEN PAGES of search results mentioning Docker in the old forums
Unless search is screwed up, I just searched for the word “Docker” and it’s showing 654 issues dating back to 2016
(I had to remove the hyperlinks since it considers me a “new user” and limits me to 2 hyperlinks
While these aren’t specific to Sandboxes, it shows that people care about using Docker on TrueNAS. You said (or implied) it yourself, posts show people care about it. Does it really matter if sandbox support wasn’t originally requested for Docker? No one is saying “SANDBOXES MUST ONLY BE USED FOR DOCKER AND NOTHING ELSE!”. People just want an easy way to use a new technology, regardless of what the end use is intended for. VMs have a ton of overheard, so why should we only be limited to that if we want to use Docker?
Like I said in one of my earlier posts, I have a pretty beefy system (24 cores/48 threads, 128 GB DDR4, 8 NVMe drives, 20+ HDDs) and for some reason running a VM with 35 Docker containers absolutely brought everything in the VM to a crawl (RAM maxed out within a few minutes and it wasn’t just cache usage, even though it had far more resources than it should have needed. Should I just accept that? Post a Jira and wait for IX to get around (not saying that they’re lazy, just that they have a lot on their plate) to helping me figure out what the issue is?
I would just like “support” for Docker. I would prefer to do it my own way, since I have everything already written the way I’m using to having it setup and could easily switch away if I wanted to.
If 10 pages of search results and 654 tickets is a “small majority” to you, I’d love to know what you’d consider a greater majority. Thousands? Tens of thousands?
So you’re saying it’s just as good even though you don’t have much experience with it? I haven’t used it in years, maybe it’s gotten better, but you can’t deny that the number of users of KVM compared to those that use Bhyve is probably like 20:1. After a quick search I couldn’t find mention of any large tech companies that use Bhyve (maybe Netflix uses it since they use FreeBSD, but I doubt it), pretty much any company that uses Linux probably also uses KVM.
And you’re limited to their poor quality UI (IMO) which is wrapped around pure qemu (unRAID does this as well, so it’s not specific to TrueNAS) instead of the industry standard of libvirt, usually managed via Red Hat Virtualization Manager or oVirt (RHVM is just the paid/Red Hat customized version of oVirt). When I have multiple disks attached to a VM there was literally no easy way to tell which attached disk was which since all that is exposed in the GUI is the boot order of the devices. You have to click into each one individually to see which zvol it is linked to. Also, see my above comment, once again, about overhead performance and other issues.
Ok dude, I get it, you hate copying and pasting They also ALL natively support Docker though. You seem to think that I’m of the mind that “plugins=bad”. If I didn’t make it clear earlier, all I’m saying is that docker-compose is the easiest solution for everyone, it allows users to automate deployments and doesn’t require IX to spend a crapload of time implementing “something that only a small minority of people want”
I’m tired of debating this with you, we’re never going to see eye to eye on this and we’re just reiterating the same tired point ad infinitum, so lets just leave it at this. Respond it you want, but I won’t be responding.
@Stux That has been my experience as well. He just appears to have his head in the sand. I can run 5 VMs under KVM with zero issues (normally, when managed and created myself via libvirt on a stock Linux OS).
myself am a supporer for jailmaker docker since that is what i used. I’m comfortable editting compose when the dev makes changes that require it. but this isn’t everyones cup of tea.
i wouldn’t want to rain on the parade of users who are probably less tech savvy compared to me, that just want a quick few clicks to get an app up and running via truenas apps/truecharts.
if you take that away, they will just skip over truenas and go for something like a synology instead.
i’m not much of a kubernetes user either since i haven’t had the time to learn it though i probably should at some point. this is the other thing some may still want.
maybe allow the users to make a choice which to use?
wish we could reduce the devs workload to focus on fewer things, but i wonder if this would backfire, because one camp will be happy but the others will get pissed off. especially the users that prefer few click quick installs for the apps, and don’t particularly care how it works under the hood other then it just installed and has a gui to start using.
i’ve used both and recommend both. works great for beginners or advanced users. These aren’t the only 2 options, but they are the one’s i’ve tried and can comfortably recommend to others.
(kidding, I realize the need for diversity)
). She’s actually not using any of the OMV features at all, operating entirely out of the NextCloud instance I fumbled up using Docker.
They also ALL natively support Docker though. You seem to think that I’m of the mind that “plugins=bad”. If I didn’t make it clear earlier, all I’m saying is that docker-compose is the easiest solution for everyone, it allows users to automate deployments and doesn’t require IX to spend a crapload of time implementing “something that only a small minority of people want”