Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Do these even work in macOS?
Outside of script compatibility, it's not what we're asking for.
*ix is sort of irrelevant. It's the certification that big businesses want so they can threaten OS vendors with canceled support contracts if the os causes trouble for their businesses.
DAZ does have a lot of plugins to get ported, and I've bought most of them, if they do port DS to Linux.
It's why even as a lifelong UNIX programmer and sysadmin I've always used Windows at home. os X, Linux, whatever, can't touch Windows desktops in number of good available apps although you must filter through a bunch of chaff in some app categories. So what that Windows Store sends app advertising to my computer and downloads updates. It's still far less intrusive than os X and Android and not vastly different than the various Linux distributions I've used that have been released in the past 10 years when they are consumer oriented distributions (I'm not talking centOS or an RT Linux of any sort here).
Hi Lipsynch and aniMate works on OSX AFAIK
Im running DS 4.7 on win7 home premuim and still have only 2.3 installed over on my older mac.
Im wondering who would be responsible for making sure the popularthird party stuff functions under linux in light of Daz's inabilty to maintain third party features that are bundeled free with DS (lipsinc for example).
"All" wouldn't happen. 4.9 doesn't run 'All' DS plugins. The majority can be made to work. ECMAscript is not magic, it is an ISO scripting language that also exists on Linux.
Kendall
Thw same folks that are for other operating systems; the initial developer of the product. If they choose not to, then there won't be support for those particular features.
My reasons to stick with Windows are rapidly dwindling.
No tools I use for my job are Windows only. Every single one of them has a native Linux version.
The games I spend most of my time on run on Linux. Some of those that don't have Linux versions planned.
What's left are a handful of apps and games that I spend a limited amount of time on. Of these Daz is the only significant one with an investment.
In a few years, I will be leaving Windows behind for good, with or without Daz.
I'm not entirely convinced the Raspberry Pi isn't a simply a pie crust with Timex Sinclair baked inside it.
If you're using OX stay clear of Mac OS Sierra while it's in beta. Someone else may hold the copyright on the name "OS X Trainwreck" but Apple is doing their dang-nest to earn that wear that crown right now. Big mistake at least at the moment.
Once I'm not able to use Windows 8.1 (still using 7) because Microsoft kills the security updates, I'll move to Mac or Linux. Never Windows 10. So, I'd be interested in a Linux version.
I'll see about posting some Alpha screenshots for you all to see.
Kendall
I don't think it will happen unless they get some clients in a big studio that really want it...which seems like a fairy tale, but I seriously doubt RHEL/CENTOS would be the way to go. Ubuntu allows closed sourced drivers to be installed even when you are first installing the OS as opposed to downloading and compiling the drivers yourself...patching the kernel, etc. So, unless redhat has caved in on their OSS only rules for the distribution, then that is a big hurdle for support. If I were managing the project, I would choose Ubuntu over redhat for that reason alone. Plus, I am pretty sure fedora has a smaller fraction of the new installs that ubuntu has. RHEL is great for backend and production stuff, but I think most of the new people coming into the linux world are tasting ubuntu first, and most probably wouldn't care for redhat in their home.
FWIW, I use both. My mac has an ubuntu VM for doing C/C++ dev work that won't compile under LLVM. But the servers I use at work are all CENTOS or Scientific Linux (which I think is CENTOS with a focus on research stuff as part of the distribution). I do have a fedora VM which I have to use to run crappy SAS garbage from time to time, but don't tell anyone:)
I didn't say they should go CentOS/RHEL, only that those are what the vast majority of commercial entities do currently support.
Ubuntu and Fedora both change far too often for any commercial concern to support. What works this month is not even close to be guaranteed to work next month on either.
But this shows that getting even a general concensus from the users will be impossible, which is why a lot of commercial software has avoided Linux in general.
I doubt DAZ will support Linux formally, not even the project I'm working on. I would like to be surprised though.
Kendall
Icom America (a commercial radio communications equipment vendor) developed a software package for their Amateur Radio division's implementation of a digital communication gateway on CentOS 5, but used the /opt path hierarchy for the installation of the gateway and any applications it required. This had some (actually, a lot) of negative impact on things; I kbow of at least one person who lost network access on the system they were using to connect to rhe internet because of security issues (nothing like getting a one hundred page report as to why to open your eyes). The one software package that I maintain runs on most flavors of Linux (x86 and ARM, ans probably x64 as well) as well as Windows and MacOS, all from thw same code baae.
I have also written code that runs on most flavors of Linux, OSX and Windows (in fact, it pays the bills
). It can be done, if the programmer knows what s/he is going. However, many programmers coming out of Colleges really have no clue how to code correctly for ONE OS much less several.
Kendall
I wrote an evaluation of a product called Top View which was, in effect, a DOS-character based version of Windows before Windows, 'allowing' a degree of multi-tasking. I think the summary was, "needs work" ;)
Wasn't Top View using Novell's extensions to DOS to allow for cooperative multitasking (as opposed to preemptive multitasking)? I vaguely remember such an item just around the time MS was sending us similar functionality for DOS that eventually became Windows.
Kendall
It was a loooooooong time ago ( I think our IBM PC-XTs were running MS-DOS 2.1) so no clear recollection except a hint of a memory that you had to supply various memory-related information for any program you wanted to use within the environement (some well-known programs, such as Word Star, had that supplied)
Giving me memories of Dbase III
Isn't it then easier to convince them to do a one-time version for most common linux distro's with a limited support of say a year? You know, kinda like Skype for Linux is working now. It's an old version nobody supports anymore since Microsoft bought it, but it works quite decently.
...I can understand the potential development nightmare with so many different versions of Linux floating around. Windows is pretty much Windows, Yes, there are updates but the OS itself has only four flavours: Home. Pro, Enterprise, and Server, which at the core level, are all pretty much the same.
All I know is that W7 will be the last Windows I will have installed on any of my systems. If there is no Linux compatible version of Daz by January 14th, 2020, I'll just have to take my chances (most likely disconnecting the workstation from the Net which will also mean no updates for my security suites and AV utilities either, and having to go back to manually installing content, plugins and updates for the Daz programme as the DIM also will not run on Linux).
Just cannot bring myself to allowing MS to dictate what goes on my system.
I've never done any serious Linux development and I don't know difficult the version differences would make it. As far as I know the Linux kernal doesn't vary much. The User interface varies depending on what Window Manager you are using, but I have installed applications that were developed for KDE on a Gnome desktop, it installed a load of libraries but this was all done automatically, the package manager sorted out the dependencies and installed everything needed to run the application.
If you do decide to disconnect from the Net you won't be getting any updates to your security software, but with no web or email you probably won't need them.
I started with dBase II ... ;) We (Steve, my colleague and I) wrote an application to allow personnel sections to do some basic look-up stuff for the members of staff in their area (read-only) to help them get used to using computers/terminals for stuff. There was a compiler for it (can't recall the name now) which we used to get it to run a bit faster and we found a bug where if you got native dBase II to page backward by passing a negative value to the command (was it the skip command?) one of them 'needed' an mathematically invalid command to work correctly, in effect passing a double negative (which should have been a positive), so had to tweak the code before compiling. Of the 2 databases/tables you could have active at a time we used 1 for the main personnel table and 1 we used for a variety of lookup tables (converting a code to a text value - for locations, etc, so something like 56015 would become M2/1 Superannuation Section)
...again, true, but the option would be leaving the system more vulnerable just to get the updates needed so it's kind of a two edged swoard.
Anyone doing cross platform development is likely to be using Qt. It is pretty much the only option that work across Linux, Win, and OSX. Even then, "works" is being generous. Gnome is GTK native and KDE is Qt native. Either environment can host applications for the other. Writing for various Linux distros is a matter of knowing what is the differences inherent to the distros.
The biggest remaining difference is the packaging. Debian based environments use the .deb package format, while everything else uses the .rpm format. The few remaining outliers may use source or tar packages. Certain distros tend to run closer to the edge than others, and these tend to use "newer" versions of libraries. A common problem is that there are contingents within each distro that DELIBERATELY make their changes to nominally compliant packages dependent on specific library versions for their preferred distro. These a-holes do it out of a desire to force other people into using their preferred setup. To manage this even with python based applications takes a bit of effort -- but they do it anyway.
In a nutshell, it isn't hard to code for Linux in a way that works in the vast majority of situations. Supporting the issues caused from people who tweak their environments to the point of breakage is the main problem.
Kendall
I tend to remember that I had a working .rpm to .deb converter at some point, that I used without problems on some packages.
I guess as long DAZ doesn't make their distro's dependent on a very personalized setup it should be possible, no? And if someone with such a super personalized setup then cannot install DAZ on his computer, I guess they could brush him off just like people could brush someone off who can't get Iray working on a 32-bit Windows XP version. Correct me if I'm wrong on this.
Indeed, but creating a Daz version that worked in say a version of Ubuntu and Fedora, or even just one of them.
It isn't about supporting everyone, but just one. It would be better still to chose a version of the OS that is designated with long-term support.
Creating a version and maintaining it - that can work with em all - is a constantly moving target seeing as new versions pop up like weeds in summer.
And those that love tweaking, would no doubt be able to get most of the functionality for their desired distro. If not, they still have that one version of Linux they can use.
I have no idea what converting from one packager to another would do, but it probably wouldn't make the binaries link properly, so if the different systems diverge much from one to another, then just changing the file locations and how dependencies are identified and whatnot wouldn't be good enough. I have had success with compiling something on an ubuntu machine and running it on RHEL before, but I'm not sure something like studio would be that easy. You'd probably have dozens if not hundreds of packages that weren't the right version, and might not even be available short of manual compilation...and...maybe you'll know which flags the other distribution used when building them? Seems like a lot of work.
Alien - http://joeyh.name/code/alien/
Let's look at another angle for max distribution on various versions of linux. Linux allows downloading of source code to compile a version for a distro. The console also Allows for pipelines.
So you could design an application to; get encrypted code, transcode it, and then the decrypted code is piped into a compiler. This process could make the DIM and some files for DAZ to run on that specific distro with less hasle then completely compiled libraries trying to work with the distro.
This would require users to have full development environments on their computers. A lot of "user centric" distrobutions, including some Ubuntu versions, do not include headers, binUtils, or the gXX compilers. VirtualBox ran into this trying to create the kernel modules from source. It didn't go well. And all they needed was the kernel headers. Something like this would need the full Qt headers, and the headers for all dependent libraries such as OpenImageIO, libsubdiv, boost, and others. We're talking over a gigabyte of headers and link libraries. Not a good way to "make friends".
Kendall