Porting GZDoom Builder to Linux

[SanyaWaffles]

If this takes off, and I can get some form of my art program to run in Wine, I can actually consider Linux a viable option after all these years!

I understand dpjudas' concerns over using third party libraries. It seems some of GZDB's problems are rooted in unstable third party dependencies. As far as I can tell, some functions not being thread safe has rendered GZDB a tad unstable. I still can't run GZDB using directories with my current project, and I can't seem to pinpoint what triggers it even with a debug build. but others have had similar issues.

I know this is specifically about Linux, but I'm hoping for the good of the community in general these fixes are integrated back into Windows somehow. I have a feeling it might make the program even more stable there. Right now it's hit or miss.

[dpJudas]

I'm not sure that the stability issues are caused by 3rd party. I think it is more likely that it could be a side effect of questionable usage of worker threads without proper synchronization primitives guarding shared data.

[SanyaWaffles]

Even if that may be, I hope those issues can still be worked out.

[Graf Zahl]

I personally find this paranoia about third party code a bit annoying. I can understand why someone wants to avoid black box code that can become a critical liability later (for me wxWidgets is such a library) but in most cases it should be easy to find out whether something is made by reliable developers or not.

I'm far more suspicious of all those high level languages that cannot be compiled to native code. They, too, can become a liability if the runtime runs into development problems. That's why I stay with natively compiled languages whenever possible.

[dpJudas]

I don't know if you can call it paranoia when OpenTK indeed did violate sound library principles by using reflection, to circumvent that classes and functions in mono are marked as internal. When that shit hits the fan the 3rd party developer will most likely shrug, mono will shrug and then YOU are one having a wonderful day explaining your customers that the product you sold can no longer work. That's the kind of liability you get from using other people's code without knowing how they actually do what they do.

OpenTK also seemed to use AGL and Carbon (for Mac) - those frameworks that Apple deprecated over a decade ago and completely dropped for 64 bit. So yeah, I feel I have a pretty good reason to distrust stuff found on the net until it has proven to me that it indeed is an exception where its worth linking to.

At work I'm using docker for some cloud azure management. Whenever I google the documentation I get a link to github, which uses a evolved/different API than what I got when I nuget installed it less than a month ago. Par for the course of what other developers produce.

[Graf Zahl]

I don't know if you can call it paranoia when OpenTK indeed did violate sound library principles by using reflection, to circumvent that classes and functions in mono are marked as internal. When that shit hits the fan the 3rd party developer will most likely shrug, mono will shrug and then YOU are one having a wonderful day explaining your customers that the product you sold can no longer work. That's the kind of liability you get from using other people's code without knowing how they actually do what they do.

OpenTK also seemed to use AGL and Carbon (for Mac) - those frameworks that Apple deprecated over a decade ago and completely dropped for 64 bit. So yeah, I feel I have a pretty good reason to distrust stuff found on the net until it has proven to me that it indeed is an exception where its worth linking to.

Well, that sounds perfectly like code to stay away from. But I still wouldn't generalize from such things. Using deprecated APIs or hacks is always a bad sign.

Also:

without knowing how they actually do what they do.

That's what I called "black box code".

I think we have the same opinion here about these things - but I still wouldn't take this as justification to stay away from third party code in general.

[dpJudas]

What annoys me is that I always have to defend my decision not to use some 3rd party library, usually multiple times (like in this thread). Every single time it boils down to other people always assume code they didn't write themselves was made by gods until I prove otherwise. And every time I do so, people say this library is the exception. Funny how I keep stumbling into those exceptions.

I'm all for using libraries when they provide significant savings in productivity. I never said all third party code is bad, but I do insist a large portion is to the degree that you are taking a risk every time you rely on one. Most people complaining about my choices never went further in evaluation than the marketing page of whatever library they found. Of course if you did your homework and looked at both the API and implementation before adding it, then I have no complaints.

[Rachael]

I really don't have a "paranoia" about third-party libraries entirely - just ones that I haven't heard about.

The bigger and more popular ones usually have bigger teams of coders on them, and more people willing to fix issues - they become more flexible and in the long run the code becomes stronger and more stable as a result. If we cut out third-party libraries completely, we'd probably have to shitcan things like OpenGL, which itself is a library unto itself, despite how deep it has to go into the OS to do its job.

When a library has proven itself to be well and good, then I have no issue with it. After all, I know GZDoom would not be where it is today, were it not for OpenAL, FluidSynth, Timidity, ZLib, DUMB, AsmJit, GME, libADL and libOPN, just to name a few - that's not even counting the biggest ones, Vulkan and OpenGL themselves. But there's a caveat to it: Some of these libraries have proven to have issues of their own, and sometimes have even had to have direct updates from their respective developers themselves. Now - let me say with no uncertainty that I am quite grateful that the developers have done that, and everyone is better for it since they did - but just imagine if they weren't there, or if they completely ignored us - and how we would get plagued with issues later on.

As dpJudas said - adopting a third-party dependency is always a risk. It might save you time - or it might cause you far more frustration and grief in the long run than if you had just done it yourself, which is especially true for smaller tasks.

And I can tell you even from just scripting things, that in general, I prefer to write my own code, than depend on someone else's, and get intertwined by whatever licensing scheme they come up with.

[SanyaWaffles]

You also run the risk of suddenly the third party development libraries ceasing development, like SlimDX did with GZDB. I dunno where the code is even hosted. If it was on Google Code it might as well be as good as lost.

It's not that I'm against the idea of third party libraries, given they are well maintained. It's when something suddenly stop being developed and no forks exist that a problem occurs.

Then again that's always a risk with anything.

[dpJudas]

Just wanted to mention that I renamed my repository. It is now called GZDoomBuilderGL. Aside from that there's no real differences, except I merged the upstream changes, Talon1024's work and updated the readme file to make it more clear how it differs from upstream.

[Gustavo6046]

Is there a reason there is no Issues tab in that repository? I hate reporting bugs on forums. Not implying I found any.

[dpJudas]

There is no issues tab as I wouldn't be using it anyway. The thing about bug trackers is that they make it feel like work. Unpaid work, that is.

[Gustavo6046]

In a way it is work, but it's a tribute. It's a hobby.

Bug trackers are very handful and tracking them via forums is a very difficult task, unless you make a subforum and make each report its own thread. Fuck bug reporting megathreads.

[Rachael]

In a way it is work, but it's a tribute. It's a hobby.

Bug trackers are very handful and tracking them via forums is a very difficult task, unless you make a subforum and make each report its own thread. Fuck bug reporting megathreads.

You can't force someone to like a tracker, especially when he sees what he hates in one, and all you're doing is making it worse by trying to push it on him.

That being said, Github supports pull requests. If you don't like forum threads, that's the best alternative.

[dpJudas]

The issue here isn't whether an issue tracker is useful or not. It is that I am not willing to fix reported bugs - if I enabled the issue tracker it would just fool people into thinking it was worth their time posting to it rather than sending it to /dev/null.

My hobby is to code various random things. I put them on github in hope it is of interest to someone else and to share it with other developers. There is no warranty on anything I put up there. If it doesn't work, send me a pull request with the fix.