sblevin
08-03-2005, 11:47 AM
Kris - This is not for/about/to you. Just starting a discussion to see if anyone is interested.
OK - I was about to release my xmame and gxmame frontend PBI's, and realised I was developing them on a slightly older box than my new flash latest everything box, so I better test them on that one first.
I go to fire up gxmame - crash! GL problems. So I think .. hey - stuff the gui - Ill try mame from the command line - CRASH! What's this???
So I tell xmame with the "-video-mode 1" option to use the X renderer, and not the OpenGL renderer. YAYYY - It goes. But probably only until I upgrade X.
GRRR! I reinstall the older nVidia drivers and OpenGL mode works just fine. SO...... when I compiled the xmame program (which is a DOG as it has no .configure file, just a well commented make file for you to hack and cross your fingers), it seems that my currently installed nVidia driver was queried about functionality, and this was made dependant on using the OpenGL renderer.
Now - I haven't compiled the xmame program with the new nVidia driver installed to see if that works YET, but I don't even want to go there there (but I will). I assume that the GL functions are still present in the new driver, but the new driver goes about it differently.
SO WHAT!
If this turns out to be the case then forget it. I'm not going to attempt recompiling and repackaging some game emulators just in case a "should be unrelated support driver" gets updated; just THINK about the horror story that leads to! Microsoft, where are you?
I'll look at this and see what I can do, but in the mean-time I had another thought....
Unbunto (I think) says it has a 6 month support cycle on versions, so that you should at least expect to get that time out of a release.
Not good enough guys.
What are we, the PC-BSD community going to do? I know there are trillions of variables here - the slow but inevitable increase in non Windows specific development support means *nix is in flux for years ... M$ knows this keeps it safe, and (in my twisted imaginings) welcomes *nix developement as it destabalises everything.
When PC-BSD gets to 1.0 and we all make homemade fireworks and get drunk and have a party, what happens then. I'm not harassing Kris here, just asking what people think.
There must (I think) be a time limit on release support, so if in my previous role as sys admin of a student windows environment I could say - OK - I'll just do security patching for one year, and spend that year building the hard disk image build for the following year. Of course it never went like that, and I had to repeatedly update the student environment with "Ohh BTW, we will be teaching AutoCad on Wednesday ....", but at least I had a STABLE environment to work on and patch.
I used to maintain a dual boot Win98/NT4 environment, and for all it's security patching and service packing was still a simple thing to do.
*nix is very different. Software is less dependant on known API's as specific versions of constantly in flux hacks and patches to great numbers of support libs. Pointing an LD path to a custom libs folder won't stop critical system upgrades breaking packages that need things like video drivers, or compat systems.
If I was to say, "OK, I'll put PC-BSD 1.0 on the student network", how long might I expect packages to work before upgrading?
(I'm not in this position anymore as I moved towns)
More importantly, what sort of "guidelines", (read: "It's just the way things are Billy") should we give to developers, so the "could be botheredness" threshold can be set?
Also, the "... but my fabulous new package requires gumbyX.ver.changes.hourly.system.lib to be installed" can be answered with, "you have to make it work with THIS.gumby.version" for inclusion into the known-good packages list.
For all the justifyable whining about M$, they do something that *nix won't get strong without. TELLING developers what to do :)
Any thoughts?
OK - I was about to release my xmame and gxmame frontend PBI's, and realised I was developing them on a slightly older box than my new flash latest everything box, so I better test them on that one first.
I go to fire up gxmame - crash! GL problems. So I think .. hey - stuff the gui - Ill try mame from the command line - CRASH! What's this???
So I tell xmame with the "-video-mode 1" option to use the X renderer, and not the OpenGL renderer. YAYYY - It goes. But probably only until I upgrade X.
GRRR! I reinstall the older nVidia drivers and OpenGL mode works just fine. SO...... when I compiled the xmame program (which is a DOG as it has no .configure file, just a well commented make file for you to hack and cross your fingers), it seems that my currently installed nVidia driver was queried about functionality, and this was made dependant on using the OpenGL renderer.
Now - I haven't compiled the xmame program with the new nVidia driver installed to see if that works YET, but I don't even want to go there there (but I will). I assume that the GL functions are still present in the new driver, but the new driver goes about it differently.
SO WHAT!
If this turns out to be the case then forget it. I'm not going to attempt recompiling and repackaging some game emulators just in case a "should be unrelated support driver" gets updated; just THINK about the horror story that leads to! Microsoft, where are you?
I'll look at this and see what I can do, but in the mean-time I had another thought....
Unbunto (I think) says it has a 6 month support cycle on versions, so that you should at least expect to get that time out of a release.
Not good enough guys.
What are we, the PC-BSD community going to do? I know there are trillions of variables here - the slow but inevitable increase in non Windows specific development support means *nix is in flux for years ... M$ knows this keeps it safe, and (in my twisted imaginings) welcomes *nix developement as it destabalises everything.
When PC-BSD gets to 1.0 and we all make homemade fireworks and get drunk and have a party, what happens then. I'm not harassing Kris here, just asking what people think.
There must (I think) be a time limit on release support, so if in my previous role as sys admin of a student windows environment I could say - OK - I'll just do security patching for one year, and spend that year building the hard disk image build for the following year. Of course it never went like that, and I had to repeatedly update the student environment with "Ohh BTW, we will be teaching AutoCad on Wednesday ....", but at least I had a STABLE environment to work on and patch.
I used to maintain a dual boot Win98/NT4 environment, and for all it's security patching and service packing was still a simple thing to do.
*nix is very different. Software is less dependant on known API's as specific versions of constantly in flux hacks and patches to great numbers of support libs. Pointing an LD path to a custom libs folder won't stop critical system upgrades breaking packages that need things like video drivers, or compat systems.
If I was to say, "OK, I'll put PC-BSD 1.0 on the student network", how long might I expect packages to work before upgrading?
(I'm not in this position anymore as I moved towns)
More importantly, what sort of "guidelines", (read: "It's just the way things are Billy") should we give to developers, so the "could be botheredness" threshold can be set?
Also, the "... but my fabulous new package requires gumbyX.ver.changes.hourly.system.lib to be installed" can be answered with, "you have to make it work with THIS.gumby.version" for inclusion into the known-good packages list.
For all the justifyable whining about M$, they do something that *nix won't get strong without. TELLING developers what to do :)
Any thoughts?