Hi Patrick,
# ffmpeg ffmpeg: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
# sudo apt install npm Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libssl-dev : Depends: libssl3 (= 3.0.9-1) but 3.0.9-2 is to be installed E: Unable to correct problems, you have held broken packages.
I agree with your points. But in my usage environment, it is more convenient to use the command line tools directly.
Then TrueNAS is not the software for you. Install Debian and do what you like with it. TrueNAS is an appliance OS--always has been, always will be. Installation of software in the appliance has never been supported, and once again that's highly unlikely to change. If you have a workflow that depends on being able to install arbitrary software in the base OS, I reiterate that TrueNAS is not the OS for you.
Hi danb35,
So is Microsoft Word. It doesn't belong on TrueNAS either.
Not a bug IMO, as (for at least the fourth time in this thread) TrueNAS is an appliance, and installing arbitrary software in it has never been supported--there's a reason, after all, that
apt is disabled by default. But if you want to make a bug report, the place to do that (surprisingly) is at the "report a bug" link at the top of this page.
I'm not here to debate or express any opinions about your knowledge of TrueNAS. I just need a viable solution. Now.
/lib/x86_64-linux-gnu/libGL.so. I copied that from Debian 12 and then, FFmpeg can work.
The only viable solution that has a strong likelihood of continuing to be a viable solution is to use different software. Period. But since you're convinced that "it won't do something it was never intended to do" is a bug, file a ticket and take it up with the devs.
I don't think you understand how software development works. Something that doesn't work is not a bug if it was never supported in the first place. The fact that you can use it at all just means it's "use at your own risk and may change or not work in the future". It's like running Hackintosh on a non Mac computer. Sure, you can do it, but when it stops working on the next version of MacOS, it's not because it's a "bug".
I am sorry, I am a developer. I understand how to build a system.
Doesn't mean anything. I'm a developer myself and I have interviewed developers not knowing how memory works or what a retain cycle/circular reference is even though that's practically CS101. Probably a lot of this is due to the fact that most newer developers work on mostly higher level languages that has automatic memory management, but I digress.
Believe being the operative keyword there. It's not the definition of software support.
When it comes to memory management, I'm familiar with the implementation of malloc in libc, but I have little understanding of how memory is charged, addressed, and other circuitry information. However, this doesn't stop me from making a living through programming. I envy you for having the opportunity to study at the prestigious Stanford University and the chance to take the CS101 course. During my studies, I once stayed up all night studying the Chinese version of "Computer Systems: A Programmer's Perspective," which is a fantastic book. I once dreamt of attending a top-tier university, but I am just an ordinary developer, working hard in a developing third-world country. Now, I can only seek assistance in a community using my rudimentary English skills.
The fact that they don't let you modify the base system is indeed a direct result of that desire to make it plug-and-play. This is done so recovery of the system (which has happened a lot in these forums) is as simple as reinstall -> upload backed up config file. Allowing the base system to be mutable basically goes against that philosophy of easily reproducible state. As for your second point about the UI, you actually are probably correct. The UI, in some places, are definitely clunky, particularly for VM's in my opinion, but it is still much better than other solutions like OMV, in my opinion.
Apologies if that's how I came off. My main goal, really, was to let you know that you probably did set your expectations a bit higher than what it should be in this particular instance since your work-around now isn't guaranteed to keep working when ixSystems releases a new version. But glad that you found a solution that worked for you though.
Make a jail, a container or a VM with all the tools you need and work in there.
Wrong assumption. There is no guarantee that these tools will even be there in the next release. Docker is the poster child for this.
The problem is that you're seeking help in making it do something it was never designed or intended to do, so in that sense, yes, I think your understanding of the software is flawed. And no, I don't think you'll get much help here in that regard. There are a few who have come up with various unsupported ways of doing things, many of which are found in the Resources, like Patrick's guide to installing TrueNAS on a partition of a boot device rather than on the whole thing. But by and large, according to my observation (and I speak only for myself as a member of the community, albeit one who's been around longer than most), the strong community ethos is to work within the system and use it as it was intended to be used, that being what gives you the best chance of stable long-term data storage--which is the prime function of the software.
I would suggest this for SCALE:
github.com
Install a VM and use that as you see fit.
