Opher Ben Peretz 882232 Posted April 8, 2011 at 06:18 PM Posted April 8, 2011 at 06:18 PM Can't agree more, with Luke, who sees things exactly as they are, and understands their implications, presently and in the future. Regards, Opher Ben Peretz Senior Instructor Link to comment Share on other sites More sharing options...
Darrol Larrok 1140797 Posted April 8, 2011 at 07:41 PM Posted April 8, 2011 at 07:41 PM Can't agree more, with Luke, who sees things exactly as they are, and understands their implications, presently and in the future. I agree. The important issue is that VATSIM needs to to be moving forward. Link to comment Share on other sites More sharing options...
Robert Bressert Posted April 10, 2011 at 10:12 PM Author Posted April 10, 2011 at 10:12 PM Well, watta ya know! viewtopic.php?f=6&t=55900 Link to comment Share on other sites More sharing options...
Dhruv Kalra Posted April 11, 2011 at 09:15 AM Posted April 11, 2011 at 09:15 AM VATSIM's founding docomeents gave a group of middle-aged men with little understanding of technology lifetime control. One should not be surprised that the network has stagnated for the past half-decade. Old men with a reverence for the status quo don't make history, or progress. Wholeheartedly agree. It's a shame that we have such a disconnect to the point where the powers that be see nothing wrong with the status quo. The mantra of inclusivity has been preached time and time again on all fronts. Frankly, modern software and network infrastructure would go a long way towards achieving that goal. What was that line about absolute power corrupting absolutely? Dhruv Kalra VATUSA ZMP ATM | Instructor | VATSIM Network Supervisor Link to comment Share on other sites More sharing options...
Andrew Wolcott 814793 Posted April 11, 2011 at 09:22 AM Posted April 11, 2011 at 09:22 AM What exactly is the point of developing a new pilot client, when the infrastructure within the network protocol does not support how real world air traffic management works. Everything is Callsign based, not CID and Flightplan. The overall structure of the network protocol needs a rewrite. We are all, both ATC and Pilots, missing out on so many advances and possibilities on this network all because of a sincere lack of interest to improve the "HOST" code. Basically, VATSIM needs a rewrite from the bottom up. The other thing we don't need is another carat dangled in front of us. Please. Link to comment Share on other sites More sharing options...
Opher Ben Peretz 882232 Posted April 11, 2011 at 11:58 AM Posted April 11, 2011 at 11:58 AM I support the call to not only push for a new client, but also to review, update and introduce new technological features to the network. Here is one reason it isn't, and likely won't be happening. Let's look at the situation from the Founders viewpoint, or even a neutral one: The network is successful in attracting new members at reasonable rate and has evolved into one of the two largest organizations No other network I'm aware of has evolved to become a serious contender, as home for serious simmers Its services are working 24/7 for this happy community, having grown in depth and width along time Five or so ATC clients have been developed and used through its ten year life, successfully. Similarly four or so pilot clients have been developed and used through this time period, incorporating feature and usage improvements and added capabilities Few real problems exist in the system. So why should the aging founder disurb his cigar smoke? is any complaint really threatening his network? the answer I believe is a clear and strong NO. Besides, Lefteris is kinda busy with his own developments with little time left for these ideas, many write about. True, on Balboa island one can lick excellent frozen bananas, but here, unfortunately, you live with 33 ice cream flavors. We need stronger arguments. Regards, Opher Ben Peretz Senior Instructor Link to comment Share on other sites More sharing options...
Tim Krajcar Posted April 12, 2011 at 12:43 AM Posted April 12, 2011 at 12:43 AM We need stronger arguments. No, you don't. The arguments are plenty strong. These "wouldn't it be nice" threads crack me up. We all know that it would be nice. It would've been nice two years ago. It sure as hell would be nice now, when there are no actively supported clients. What you need are a few "I'll give it a try. Who's with me?" threads. Tim Krajcar Link to comment Share on other sites More sharing options...
Jonas Eberle Posted April 12, 2011 at 03:59 AM Posted April 12, 2011 at 03:59 AM ... +1. It is basically simple to see that the technical infrastructure is structurally aged to any one having a bit of insight. Link to comment Share on other sites More sharing options...
Wycliffe Barrett Posted April 12, 2011 at 10:28 AM Posted April 12, 2011 at 10:28 AM I'm afraid you may have gotten hold of the wrong end of the stick with my comments. FSinn has never caused me an issue. I can and have many times downloaded the software and installed it onto a pc and have it up and running in 5 mins. Thats because perhaps that I have been using it for so long and know of some of the vagaries about it. SBOx is the same up and running in no time at all. So back to the OP we do have two clients that work. But..... I certainly agree that some redundancy is required and rest [Mod - Happy Thoughts]ured if I had any kind of skill at all in programming I suspect i would try and have a go at writing a client, but I don't so can't. I know Luke you have expertise in that arena and I suspect if the NDA was not in existence you yourself might have ago at creating a new client. With the obvious talent within VATSIM it is always a surprise to me when this topic comes upi that someone doesn't say hold on "I'll give it a go". but who knows it could already be happening. Wycliffe Wycliffe Barrett: C3 Controller "if god meant for us to fly, he would have given us tickets" Mel Brooks Link to comment Share on other sites More sharing options...
Robert Bressert Posted April 12, 2011 at 02:57 PM Author Posted April 12, 2011 at 02:57 PM Remember, I've only been around here for a year, so please take that into account, but why could IVAO develop client software and we can't, or haven't been able to up to this point in time? Am I right in understanding that FSINN and SB were already-developed softwares that Vatsim adopted and adapted? Is Luke right? And, I truly am not trying to be abrasive, but is the problem a systemic problem within our community that precludes even the possibility of development of new client software? So, what needs to change? Can things change? I ask those questions only with the deepest sense of gratitude for all the hard work by those who allow me to enjoy the greatest hobby on this planet and a deep respect for the founders and leaders of our community. I only want to see Vatsim become greater for all of us. Link to comment Share on other sites More sharing options...
Wycliffe Barrett Posted April 12, 2011 at 04:50 PM Posted April 12, 2011 at 04:50 PM Remember, I've only been around here for a year, so please take that into account, but why could IVAO develop client software and we can't, or haven't been able to up to this point in time? Am I right in understanding that FSINN and SB were already-developed softwares that Vatsim adopted and adapted? Robert The founders of VATSIM created the VATSIMnetwork on the proviso that it will lawys be free to use to the end user, (pilots and controllers) and that all user software apart from initial setup costs (flight simulators and computers) be free. They have specific agreements with developers much of which is quite compliated which ensures that any software developed remains the property of VATSIM (Ithink) Luke understands all that better than. It is linked in with some of the propriatery software that VATSIM uses hat the fopunders do not want others to use. IVAO on the other hand actaully seek financial support from certain individuals and organisations such as Aerosoft who then have some say in how IVAO can be run. Also it does mean that if Aerosoft went bust and lost its revenue then IVAO nmight be in danger of closing down. Thisis a highly potted history and there are some others apart from me who know the entire detail of this. Wycliffe Wycliffe Barrett: C3 Controller "if god meant for us to fly, he would have given us tickets" Mel Brooks Link to comment Share on other sites More sharing options...
Luke Kolin Posted April 12, 2011 at 05:31 PM Posted April 12, 2011 at 05:31 PM I suspect if the NDA was not in existence you yourself might have ago at creating a new client. With the obvious talent within VATSIM it is always a surprise to me when this topic comes upi that someone doesn't say hold on "I'll give it a go". For what it's worth, I have signed the NDA and I have done some work with the VATSIM software stack, getting to the point of a DLL to deal with the wire protocol with FSD. Admittedly, the NDA stops a fair number of developers. But it's one layer of the onion - there are a lot of other impediments. The first, and largest, is that writing a pilot client is HARD WORK. It has a lot more integration points than an ATC client, and what makes things even harder is that you're dealing with a six year old simulator using a deprecated API (DirectPlay) that doesn't support Microsoft's latest programming framework. That's just for FS8/FS9; FSX isn't much better and doesn't even have a docomeented multi-player interface. It's really the kind of task that you need several people for, or at least start with an existing code base so you're not constantly reinventing the wheel from scratch. We don't seem to do that in the VATSIM world. I honestly don't know why. They have specific agreements with developers much of which is quite complicated which ensures that any software developed remains the property of VATSIM (I think) I believe you have it exactly backwards. VATSIM has NO rights to the source code of the pilot clients that I am aware of - they have a legal arrangement with the authors that allows them to redistribute the compiled code in perpetuity, but no ability to fork the code or transfer ownership. That's entirely the root of the problem I think - if they had that ability they would have just gotten some of the NDA'd developers to fix the existing bugs in SB or FSINN and be done with it. In retrospect, I think VATSIM made a fundamental strategic error in their legal and software strategy. They dramatically overvalued their propriety IP and based their legal strategy around restricting and "protecting" it, despite the fact that software becomes obsolete faster than anything else in history. They paid next to no attention to continuity of operations, and didn't create licensing terms that would give them the right to fork if the developer moved on to different things. A condition of writing a pilot or ATC client would have been that VATSIM received the rights to reuse the source if the developer didn't make a new release within a certain period. I've had external developers write critical software for Delta Virtual and Air France Virtual, and at the core of each relationship was an agreement that each party had unrestricted rights to use the source going forward. We were protected in case the developer lost interest, and the developer had the right to reuse anything they created for their own purposes, commercial or non-commercial. It was a mutually beneficial relationship that at its core protected our VAs from our biggest danger. That biggest danger isn't copying of our software, or someone making a billion dollars from it. Good for them if they do! Our biggest danger is of losing developers, and maintaining continuity of development. It's VATSIM's biggest danger, and it's obvious today. I don't think they considered it such in the past, and I seriously question whether they do now. Cheers! Luke ... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts. ... Normal in my household makes you a member of a visible minority. Link to comment Share on other sites More sharing options...
Ross Carlson Posted April 12, 2011 at 06:27 PM Posted April 12, 2011 at 06:27 PM It's really the kind of task that you need several people for, or at least start with an existing code base so you're not constantly reinventing the wheel from scratch. We don't seem to do that in the VATSIM world. I honestly don't know why. VATSIM does provide a networking layer and a voice layer so developers don't have to rewrite those pieces. Saved me boatloads of time when I wrote VRC. In fact, I doubt I would have written VRC if the voice stuff wasn't already taken care of. That's just not a nut I would want to try to crack for a hobby project. And I've provided chunks of my code to other developers, such as sector file parsing code, and scope/target drawing code. And Joel provided me with his multiplayer code to enable the tower view in VRC. So not every developer reinvents all four wheels every time. Obviously, the amount of code reuse that has occurred represents only a fraction of the work required for a complete pilot client that supports all the popular sims, and thus your point about writing a pilot client being hard work is entirely true. I'm not sure what VATSIM can do to increase the level of code reuse other than to encourage developers to modularize their code as much as possible and make it available to any dev that wants it. Luke, I'd love to hear your thoughts on that. That biggest danger isn't copying of our software, or someone making a billion dollars from it. Good for them if they do! Our biggest danger is of losing developers, and maintaining continuity of development. It's VATSIM's biggest danger, and it's obvious today. I don't think they considered it such in the past, and I seriously question whether they do now. When I completed VRC, and we were putting together the license for VATSIM use, VATSIM requested that they have the ability to hold the source code in escrow so that they could maintain it in the event that I abandoned it and it stopped working on VATSIM. So for what it's worth, they were thinking in terms of continuity at least around the time I released VRC. I don't know whether or not a similar request was made for SB3, SB4, or FSInn ... obviously the request could have been made and turned down and VATSIM would still accept the free software. Again, I don't have the answer ... I don't know what the magic bullet is in terms of what VATSIM could do to improve the situation. Sure, VATSIM could require that any software developed for VATSIM come with a license allowing VATSIM to fork/reuse the code, but would all potential developers agree to that? In the past I've suggested that VATSIM could spearhead an effort to [Mod - Happy Thoughts]emble a team of developers to write a new pilot client and VATSIM would retain rights to use the code however it wanted. I don't know how well that would work, but I do think it's worth a try. Getting rid of the NDA would probably help expedite putting the team together. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Robert Bressert Posted April 12, 2011 at 06:38 PM Author Posted April 12, 2011 at 06:38 PM This thread is giving me a headache. I think I'm gonna go fly! Link to comment Share on other sites More sharing options...
Luke Kolin Posted April 13, 2011 at 12:34 AM Posted April 13, 2011 at 12:34 AM VATSIM does provide a networking layer and a voice layer so developers don't have to rewrite those pieces. Saved me boatloads of time when I wrote VRC. In fact, I doubt I would have written VRC if the voice stuff wasn't already taken care of. That's just not a nut I would want to try to crack for a hobby project. And I've provided chunks of my code to other developers, such as sector file parsing code, and scope/target drawing code. And Joel provided me with his multiplayer code to enable the tower view in VRC. So not every developer reinvents all four wheels every time. Let me throw out a partial guess, and you tell me what you think of it - people are writing less C these days. I agree with you that there's PCSB and the VVL, and if you're a C developer you can graft these libraries onto your app and you're off to the races. But I wonder just how many C developers there are in the ecosystem these days. There's been a tremendous rise in non-C languages over the years. If you're creating Windows apps, in most cases you can do something in C# (or before, in VB) and there's very little performance-critical code in a pilot or ATC client. With modern, memory-manged languages with simplified build/compilation systems, you can develop stuff a lot faster that you could in C since there's less house-keeping to worry about. I don't care about header/source files, or malloc() and free(). I spend more time writing application logic than housekeeping code. Almost every language ecosystem has settled around the idea of a VM, and in most cases the performance delta with native C code is so small that it doesn't really matter anymore. Everything I write for DVA runs in a VM, and same thing at work. One of the advantages of the major VMs is that they support multiple languages - on the JVM at weather.com we run Java and Scala, and on the CLR we use C# and F#, both functional and imperative languages. I think something similar would benefit VATSIM, and that's one of the efforts that I was doing; creating a .NET equivalent to the PCSB library to allow you to connect to FSD and abstracting away all of the protocol messages. There was also a little bit of work to p[Mod - Happy Thoughts] the servinfo feed, load the server list and calculate the "best" server based on ping times. Whether that's of value or not (I've been told both publicly and privately that it was not perceived to be of value) I think we need to create .NET versions of the common code (protocol, voice and multi-player) with well-defined interfaces. Very folks write C anymore. With the CLR, Microsoft has given us a way to mix and match languages where it makes sense. We should take advantage of it. I don't know whether or not a similar request was made for SB3, SB4, or FSInn ... obviously the request could have been made and turned down and VATSIM would still accept the free software. That's a problem there; had you insisted on complete ownership of ACARS code seven years ago I would never have said yes, despite the fact that it was a critical strategic need. Someone suggested to me recently that this issue is a little more complicated than it appears at first glance - how do we define active maintenance, and what are the implications? Let's say, hypothetically, that after a release or two of your vSTARS client a bunch of aviation universities get really interested, and start licensing the code for $75,000 apiece. Good for you! Even better, you get so busy supporting your paying clients that you really don't have time to maintain the VATSIM version of your software. Is it still under active development? That's probably a question that three lawyers can give you four different answers to - this non-lawyer can see both sides of the argument. But if you've given VATSIM the unrestricted ability to fork if "not under active maintenance" and potentially release it into the public domain, you've got a real risk to your livelihood because someone could turn around and resell your product for significantly less. If I was your corporate counsel thinking of nothing more than the income of Ross Carlson, I'd be at the very least sending over a nastygram to VATSIM arguing that just because you weren't maintaining the VATSIM version doesn't mean that they can release the source. Hypothetical? Yes. Hyperbole? Probably. But the point is that I've heard enough stories of a mix between commercial and hobbyist development that I wouldn't be surprised if the legal structures were very ambiguous. And yes, I don't know if SB3 was ever under such a restriction - all I've heard is that an authoritative source told me that the source was unlikely to be released. The specific reason? I'll never know for sure, but we need to at least stop putting the organization in such a circomestance. That's the second part of the equation - we've got to stop starting from scratch each time. Sure, VATSIM could require that any software developed for VATSIM come with a license allowing VATSIM to fork/reuse the code, but would all potential developers agree to that? Probably not. We'd lose a certain percentage, but I question how much the organization would lose as a whole. In the long run, it doesn't do us much good to have three pilot clients that turn out to be abandonware. I think it would be better to have one or two that survived multiple generations of developers. VATSIM has been around for over a decade; and we're on our third generation of ATC and pilot client developers. It's pretty much an accepted fact that the software will outlive the developers; let's create a structure that recognizes this, allows for this and lets both VATSIM and the developers progress and profit. In the past I've suggested that VATSIM could spearhead an effort to [Mod - Happy Thoughts]emble a team of developers to write a new pilot client and VATSIM would retain rights to use the code however it wanted. I don't know how well that would work, but I do think it's worth a try. Getting rid of the NDA would probably help expedite putting the team together. I suggested to Richard a few years ago that VATSIM needed to reorganize its IT infrastructure around the model of a corporate IT group. It was a technology organization that fundamentally needed to act like one. Part of that is recognizing that development of any client has probably exceeded the scope of a single individual, and to organize teams to create and maintain it. Yes, it involves people doing from time to time something that they don't immediately want to do. That's also part of being a grownup, and working towards a goal that is greater than individual gratification. An OSS model allows this organization to come together on its own (although it's not guaranteed to accomplish this). If we're not going to do that, we should at least recognize that the NDA on balance is more of a negative than a positive. It adds a bureaucratic, time-consuming step, and it adds IP worries and encomeberances. What ultimately killed my VATSIM development career was that I was never able to get an authoritative answer as to whether outside code I introduced into my VATSIM libraries would get encomebered by the NDA. For what it's worth, I think it's a great thing to have these discussions. VATSIM doesn't often engage in discussions regarding strategic direction, and none of us (not even me, believe it or not!) has all the answers, or at least all of the right ones. I'm glad we're discussing the solutions. Cheers! Luke ... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts. ... Normal in my household makes you a member of a visible minority. Link to comment Share on other sites More sharing options...
Ross Carlson Posted April 13, 2011 at 01:40 AM Posted April 13, 2011 at 01:40 AM Let me throw out a partial guess, and you tell me what you think of it - people are writing less C these days. True, but with C# you can still make use of C libraries. I did not have to rewrite VVL to use it in vSTARS, which is a C# app. Can't Java load C DLLs too? Also, I could have used VATSIM's existing networking library for vSTARS, but I decided I wanted to write my own in managed C#. That was my own personal choice. Nothing was forcing me to reinvent that wheel. I simply wanted to write the library, I guess for the challenge. And once my .NET library and my .NET VVL wrapper are proven via the vSTARS beta, I'll be giving them to VATSIM. I don't know whether or not a similar request was made for SB3, SB4, or FSInn ... obviously the request could have been made and turned down and VATSIM would still accept the free software. That's a problem there; had you insisted on complete ownership of ACARS code seven years ago I would never have said yes, despite the fact that it was a critical strategic need. Are you saying it would have been better for VATSIM to refuse SB3 and FSInn and instead hope that someone would develop a pilot client and be willing to give VATSIM rights to the code? I guess I can't blame VATSIM for not making that gamble. I agree that accepting SB3 and FSInn put VATSIM at risk of having its core software become abandonware (how could I not agree ... proof is in the pudding) but at the same time, accepting SB3 and FSInn does not preclude *also* accepting a client from someone willing to give the source to VATSIM. I guess one could argue that if VATSIM had not accepted SB3 and FSInn, it would create a vacuum and there would be much more incentive for someone to write a client and give the source to VATSIM. That makes sense in theory, but it's also wishful thinking. I think it's also quite possible that VATSIM would have languished and eventually shut down before someone stepped up ... we'll never know, I suppose. Someone suggested to me recently that this issue is a little more complicated than it appears at first glance - how do we define active maintenance, and what are the implications? Let's say, hypothetically, that after a release or two of your vSTARS client a bunch of aviation universities get really interested, and start licensing the code for $75,000 apiece. Good for you! Even better, you get so busy supporting your paying clients that you really don't have time to maintain the VATSIM version of your software. Is it still under active development? That's probably a question that three lawyers can give you four different answers to - this non-lawyer can see both sides of the argument. But if you've given VATSIM the unrestricted ability to fork if "not under active maintenance" and potentially release it into the public domain, you've got a real risk to your livelihood because someone could turn around and resell your product for significantly less. If I was your corporate counsel thinking of nothing more than the income of Ross Carlson, I'd be at the very least sending over a nastygram to VATSIM arguing that just because you weren't maintaining the VATSIM version doesn't mean that they can release the source. Yeah, defining the terms of the license is certainly important. Each developer will have his own sensitivities in that area. I'd have to go back and read it, but if I remember right, my deal with VATSIM on VRC precluded their use of my code for anything but the non-commercial VATSIM. They couldn't go sell it. Probably not. We'd lose a certain percentage, but I question how much the organization would lose as a whole. In the long run, it doesn't do us much good to have three pilot clients that turn out to be abandonware. What's better, three clients that end up as abandonware, or zero clients? It goes back to the same question as above ... does refusing the potentially-abandonware clients raise the likelihood of obtaining non-potentially-abandonware clients? I would like to believe that it does, but again I'm not sure that's not just wishful thinking. Anyway, my whole point was to illustrate that at least in the case of VRC, VATSIM was definitely thinking along the right lines, because they wanted to make sure they could maintain the code if I decided not to. I think it would be better to have one or two that survived multiple generations of developers. I doubt anyone would disagree with you there... VATSIM has been around for over a decade; and we're on our third generation of ATC and pilot client developers. It's pretty much an accepted fact that the software will outlive the developers; let's create a structure that recognizes this, allows for this and lets both VATSIM and the developers progress and profit. How do we do that? I think your answer is here: I suggested to Richard a few years ago that VATSIM needed to reorganize its IT infrastructure around the model of a corporate IT group. It was a technology organization that fundamentally needed to act like one. Part of that is recognizing that development of any client has probably exceeded the scope of a single individual, and to organize teams to create and maintain it. Yes, it involves people doing from time to time something that they don't immediately want to do. That's also part of being a grownup, and working towards a goal that is greater than individual gratification. An OSS model allows this organization to come together on its own (although it's not guaranteed to accomplish this). If we're not going to do that, we should at least recognize that the NDA on balance is more of a negative than a positive. It adds a bureaucratic, time-consuming step, and it adds IP worries and encomeberances. What ultimately killed my VATSIM development career was that I was never able to get an authoritative answer as to whether outside code I introduced into my VATSIM libraries would get encomebered by the NDA. So, to summarize, the way we get there is to: a) Nuke the NDA. b) Organize a team that is willing to not always be working on the fun bits, and is willing to not have total control of the source they generate. Would you add: c) Refuse work from individuals not willing to give VATSIM rights to their code ? Regardless of whether or not we need item C, I think A and B would be great first steps. I find myself wishing I had more time to devote to VATSIM so that I could help build and manage this team. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Luke Kolin Posted April 13, 2011 at 02:54 AM Posted April 13, 2011 at 02:54 AM True, but with C# you can still make use of C libraries. I did not have to rewrite VVL to use it in vSTARS, which is a C# app. Can't Java load C DLLs too? Oh, you can. And maybe the .NET wrapper around VVL is just a little bit of C# that does the P/Invoke to a DLL that has VVL in it. However, it's worth mentioning that it's not a skill that the average C# developer has, nor is it something we should require as a matter of course. (And yes, Java can call C DLLs and there's even a Java interface to FSUIPC. It's an act of supreme masochism and self-loathing to use it.) It's a great thing that you're going to release a .NET interface layer to the VVL. It's a very necessary part of the software ecosystem and we should do more of it. We should have done it six years ago, but that's water under the bridge and it's better to do it now than not at all. How can other developers help you in that task? Are you saying it would have been better for VATSIM to refuse SB3 and FSInn and instead hope that someone would develop a pilot client and be willing to give VATSIM rights to the code? I guess I can't blame VATSIM for not making that gamble. As you correctly point out, there's a fair bit of conjecture in both of our positions that we'll never know either way. You're right in that if I was VATGOV5 seven years ago instead of a pundit, it'd be a bit more of a gut-check moment to actually make the call and take responsibility for it. As objectively as I can, I think I'd still have said no - at least the first time. If I had turned away a first client because of principle and was in a similar situation with a second? Who knows. It is worth noting, however, that a) the absence of a client might have spurred others, and b) we weren't dead in the water in 2004, either. We still had SB2.3, SBRelay and AVC and while kludgey it wasn't much worse than what we have now. Anyway, my whole point was to illustrate that at least in the case of VRC, VATSIM was definitely thinking along the right lines, because they wanted to make sure they could maintain the code if I decided not to. Right. So I wonder if the pilot clients were licensed under similar terms, and if not, why not? Are future pilot clients licensed under different terms that would prevent this from happening again? Regardless of whether or not we need item C, I think A and B would be great first steps. I find myself wishing I had more time to devote to VATSIM so that I could help build and manage this team. I think some variant of C is necessary, but I'm not especially dogmatic on it. What I would be insistent upon some terms that recognized that the software would outlast its original creator, giving VATSIM flexibility? Absolutely. I'd love to give VATSIM time to do that, too. And like you, I've got other time commitments that are sucking me up and I fear that my lifetime as a VATSIM or FS developer is more or less p[Mod - Happy Thoughts]ed, too. I think the goal of a team-oriented tech group is valid, and it needs to exist in two places - one with Wade on the software development side, and one with Luca on the server admin side. There are plenty of tools and technologies that either can leverage that didn't exist 10 years ago that could either dramatically improve the service VATSIM provides or reduce the costs. Maybe serving ServInfo feeds via S3? Using open-source monitoring for critical infrastructure? Using EC2 for FSD or the data server? Interesting possibilities. Cheers! Luke ... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts. ... Normal in my household makes you a member of a visible minority. Link to comment Share on other sites More sharing options...
Ross Carlson Posted April 13, 2011 at 04:22 AM Posted April 13, 2011 at 04:22 AM How can other developers help you in that task? I don't think I need any help getting the libs released to VATSIM, but obviously it would be good if devs could contribute bug fixes and improvements down the road. So my hope is that the VP Dev will put them into a version control system that any dev can access. I'm not expecting that to be a problem ... we've had the VVL and PCSB code in CVS in the past. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Richard Jenkins Posted April 13, 2011 at 04:48 AM Posted April 13, 2011 at 04:48 AM So, to summarize, the way we get there is to: a) Nuke the NDA. b) Organize a team that is willing to not always be working on the fun bits, and is willing to not have total control of the source they generate. Would you add: c) Refuse work from individuals not willing to give VATSIM rights to their code Ross, as we talked about - IMO if we could get the server hardened and stop trying to enforce security on the client side we could do away with the NDA and some of the other headaches and open up many things for inquiring minds. RJ Link to comment Share on other sites More sharing options...
Tim Krajcar Posted April 13, 2011 at 05:20 AM Posted April 13, 2011 at 05:20 AM Definitely, RJ. That's the best solution.... Tim Krajcar Link to comment Share on other sites More sharing options...
Wycliffe Barrett Posted April 13, 2011 at 09:17 AM Posted April 13, 2011 at 09:17 AM Hi After reading page 3 of this thread, my greatest regret is that I never continued learning code after the ZX Spectrum. Any support I can offer, all you have to do is holler. Wycliffe Wycliffe Barrett: C3 Controller "if god meant for us to fly, he would have given us tickets" Mel Brooks Link to comment Share on other sites More sharing options...
Andrew Doubleday Posted April 13, 2011 at 09:54 AM Posted April 13, 2011 at 09:54 AM VATSIM's founding docomeents gave a group of middle-aged men with little understanding of technology lifetime control. One should not be surprised that the network has stagnated for the past half-decade. Old men with a reverence for the status quo don't make history, or progress. My attention was just brought to this one... sorry could help but +1 this comment... Andrew James Doubleday | Twitch Stream: Ground_Point_Niner University of North Dakota | FAA Air Traffic Collegiate Training Initiative (AT-CTI) Graduate Link to comment Share on other sites More sharing options...
Richard Jenkins Posted April 13, 2011 at 05:07 PM Posted April 13, 2011 at 05:07 PM VATSIM's founding docomeents gave a group of middle-aged men with little understanding of technology lifetime control. One should not be surprised that the network has stagnated for the past half-decade. Old men with a reverence for the status quo don't make history, or progress. My attention was just brought to this one... sorry could help but +1 this comment... Yeah, +1 RJ Link to comment Share on other sites More sharing options...
Alexander Nolting 887789 Posted April 13, 2011 at 09:47 PM Posted April 13, 2011 at 09:47 PM Luke, social analysis: ++1 technical analysis: --1 You need trying to develop a pilot client in Java/C# to see what I mean. You definitely need to have a look to FS and OS API's. FSInn actually took advantage of VB6, but because it compiles to native code and is only used for the user interface. When you decide to live in a completely protected VM world, you can't expect to efficiently hack arround the native API that gives you not the features you desperately need. The FS client world is a real time world, you need saving every extra time consuming bit you can get. Remember that you are adding extra code into the FS process and its rendering queues. I wish I could write english more fluently, to put my view in such many fitting words as in your social analysis. I like adding that there is a ticking time bomb for the network, called "Flight!". Is it too late or early enough to make this bomb less harmful? “the biggest enemy of freedom are happy slaves“ Link to comment Share on other sites More sharing options...
Luke Kolin Posted April 13, 2011 at 11:28 PM Posted April 13, 2011 at 11:28 PM You need trying to develop a pilot client in Java/C# to see what I mean. You definitely need to have a look to FS and OS API's. FSInn actually took advantage of VB6, but because it compiles to native code and is only used for the user interface. When you decide to live in a completely protected VM world, you can't expect to efficiently hack arround the native API that gives you not the features you desperately need. The FS client world is a real time world, you need saving every extra time consuming bit you can get. Remember that you are adding extra code into the FS process and its rendering queues. If there's a drawback to using a VM, I'm missing it somewhere. Our ACARS 2 software was written using C# and hooks into FS8/FS9/FSX using FSUIPC. The entire loop to read multiple FSUIPC offsets is around 15ms on my machine, and I imagine the time spent inside FS is a lot less than that. The program detects the core count and CPU speed, and if it's high enough will start polling FSUIPC at 6-8Hz at certain critical points. No one has ever reported a speed issue. Part of the reason is that I'm not running in-process with the sim. I don't think you could write anything in-process in non-native code, and to me it's a poor choice for a number of reasons. If you crash, you can crash/pause the sim, and more importantly you're competing with the sim as you correctly point out for clock cycles. Running in a separate process means that you can run on a different core, of which we have plenty these days. What am I missing? I was originally worried about the performance myself, but have never seen anything to lead me to question whether it's an issue. Cheers! Luke ... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts. ... Normal in my household makes you a member of a visible minority. Link to comment Share on other sites More sharing options...
Recommended Posts