Reimplementing AFV for Linux

[Pedro Rodrigues 1377186]

I'm currently considering implementing AFV my self to control under Linux. Way out of my league at the moment so would highly appreciate someone joining in.

 

Anyone interested in such attempt?

[Tobias Dammers]

There is working AFV support in Swift, which also works on Linux. Maybe look into that rather than reinventing the wheel?

[Matthew Woerly]

Sounds like he's looking for a way to do ATC on Linux, and there's no way to do that natively. Some of the radar clients in my experience run okay-ish under Wine, with some issues. There are other threads here suggesting it's not easy getting the AFV standalone client to work with Wine.

 

The audio itself might not be so bad if you use the Xsquawkbox implementation but I'm guessing some of the authentication with VATSIM would need permission from the VATSIM to implement. I'd just as well wait until the clients have native AFV support which has been hinted for sometime this year.

[Tobias Dammers]

Ah, right, yes. Might still be worth it to get in touch with the Swift team - much of their work is open source, so it might be possible to just extract the AFV parts and reuse those. Maybe even turn them into a library. I have no idea what the source code looks like though, so it may or may not be worth it.

[Nestor Perez]

You can always join the VATSIM Dev Team by sending an email to vpdev(at)vatsim.net and offer yourself to build a native Linux client

[Pedro Rodrigues 1377186]

There is working AFV support in Swift, which also works on Linux. Maybe look into that rather than reinventing the wheel?

 

Thank you. Yes, it is a very valid implementation. It is in C++ which I'm not very familiar with.

 

 

 

I'm sorry to pick you, but you started it. Since the invention of the wheel, we have engineered all kinds of wheels. Cart wheels, artillery wheels, flywheels, wire wheels, train wheels, just to name a few. Perhaps most notably, gears.

 

There are many kinds of wheels, none of which is a replacement for the other. Inventing and engineering are not synonymous. None of the engineers that design the various types of wheels we have today, have invented the wheel or have tried to do so, yet their contraptions are useful in their own domain and not necessarily applicable in another.

 

Whoever invented the wheel in the first place, I'm sure would be very impressed with gears.

 

That is analogous to someone say about C++, 'why reinventing C?'

Edited January 7, 2020 at 02:15 PM by Guest

[Pedro Rodrigues 1377186]

Sounds like he's looking for a way to do ATC on Linux, and there's no way to do that natively. Some of the radar clients in my experience run okay-ish under Wine, with some issues. There are other threads here suggesting it's not easy getting the AFV standalone client to work with Wine.

 

The audio itself might not be so bad if you use the Xsquawkbox implementation but I'm guessing some of the authentication with VATSIM would need permission from the VATSIM to implement. I'd just as well wait until the clients have native AFV support which has been hinted for sometime this year.

 

That is correct. Before AFV I could control on Linux. Since AFV I cannot get a solid setup. Mostly due to AFV current implementation.

[Pedro Rodrigues 1377186]

Ah, right, yes. Might still be worth it to get in touch with the Swift team - much of their work is open source, so it might be possible to just extract the AFV parts and reuse those. Maybe even turn them into a library. I have no idea what the source code looks like though, so it may or may not be worth it.

 

Their source code is available in https://dev.swift-project.org/source/pilotclient/

[Pedro Rodrigues 1377186]

You can always join the VATSIM Dev Team by sending an email to vpdev(at)vatsim.net and offer yourself to build a native Linux client

 

Thanks Nestor. NDAs and closed source, NO.

 

But you can always change that. Couldn't you?

[Nestor Perez]

VATSIM doesn't force you to make closed source software. I'm pretty sure client devs are free to open source their code at their liking (except for one very-precise part, for security purposes). Swift is an example of this.

 

I don't know if you've been on the VATSIM Dev Team before, but I know I haven't seen you around it since I've been part of it, which leads me to think you're talking about an NDA which you haven't ever seen by yourself. In the past years VATSIM has been changing significantly, and that includes moving slowly towards a more open-sourced mindset.

 

I am not here to force you into the team, nor am I responsible for it (I'm just a random developer that's part of it), but I really can't emphasise this enough: Join us, try it and then, decide

[Pedro Rodrigues 1377186]

VATSIM doesn't force you to make closed source software. I'm pretty sure client devs are free to open source their code at their liking (except for one very-precise part, for security purposes). Swift is an example of this.

 

I don't know if you've been on the VATSIM Dev Team before, but I know I haven't seen you around it since I've been part of it, which leads me to think you're talking about an NDA which you haven't ever seen by yourself. In the past years VATSIM has been changing significantly, and that includes moving slowly towards a more open-sourced mindset.

 

I am not here to force you into the team, nor am I responsible for it (I'm just a random developer that's part of it), but I really can't emphasise this enough: Join us, try it and then, decide

 

I don't think I can adequately show my appreciation to the effort I see you put in. Thanks.

 

You are correct, I haven't seen the NDA or have I been a member of the dev team.

 

Nor do I want to read it or be a member of said team. With all due respect for their efforts. I appreciate the invite, and this is a discussion I had with a board member before, but I just want to send some patches.

[Christopher Collins]

The AFV-Native implementation, which XSB uses, is also open sourced under the BSD license. See https://github.com/xsquawkbox/AFV-Native.

[Tobias Dammers]

I'm sorry to pick you, but you started it. Since the invention of the wheel, we have engineered all kinds of wheels. Cart wheels, artillery wheels, flywheels, wire wheels, train wheels, just to name a few. Perhaps most notably, gears.

 

There are many kinds of wheels, none of which is a replacement for the other. Inventing and engineering are not synonymous. None of the engineers that design the various types of wheels we have today, have invented the wheel or have tried to do so, yet their contraptions are useful in their own domain and not necessarily applicable in another.

 

Whoever invented the wheel in the first place, I'm sure would be very impressed with gears.

 

That is analogous to someone say about C++, 'why reinventing C?'

 

Easy there. All I meant to say was "someone has already done it, it works, it's open source, so why don't you look there before deciding to do all the work yourself?"

 

There may be valid reasons for making your own from-scratch implementation, but you haven't stated any, and when talk about "reimplementing the wheel", I really mean that it's a good idea to either use what's already there, or be confident about your reasons not to.

[Pedro Rodrigues 1377186]

I'm sorry to pick you, but you started it. Since the invention of the wheel, we have engineered all kinds of wheels. Cart wheels, artillery wheels, flywheels, wire wheels, train wheels, just to name a few. Perhaps most notably, gears.

 

There are many kinds of wheels, none of which is a replacement for the other. Inventing and engineering are not synonymous. None of the engineers that design the various types of wheels we have today, have invented the wheel or have tried to do so, yet their contraptions are useful in their own domain and not necessarily applicable in another.

 

Whoever invented the wheel in the first place, I'm sure would be very impressed with gears.

 

That is analogous to someone say about C++, 'why reinventing C?'

 

Easy there. All I meant to say was "someone has already done it, it works, it's open source, so why don't you look there before deciding to do all the work yourself?"

 

There may be valid reasons for making your own from-scratch implementation, but you haven't stated any, and when talk about "reimplementing the wheel", I really mean that it's a good idea to either use what's already there, or be confident about your reasons not to.

 

 

Thanks, I'm very glad you took it with right amount of salt.

 

Yes. what ever is done already, providing the licenses are permissible enough to allow modification and redistribution, they are very good candidates. At the moment I'm more in search for how accepted such a project might be by the community. And being fully honest, there isn't much interest I can see from here.

[Christopher Collins]

Yes. what ever is done already, providing the licenses are permissible enough to allow modification and redistribution, they are very good candidates. At the moment I'm more in search for how accepted such a project might be by the community. And being fully honest, there isn't much interest I can see from here.

 

I'm not sure what you expected to be honest - VATSIM ATC is very windows-centric. We don't even have a native macOS client, and that's a much larger slice of the pie.

 

I have a bit of a "build it and they will come" type attitude to this stuff. We have little to no precedent for non-Windows ATC users, but we don't make it easy for them by lacking the native software. If we build it, maybe there'll develop enough of a population who cares. Maybe we won't. We really won't know until we try.

 

As for using the existing AFV-client implementations, if you've dealt with OO languages before, learning C++ isn't too bad, but you can avoid having to deal with too much yourself by using swig or another ABI/FFI compatibility tool to wrap the C++ API into a C one. You can potentially also write your own wrapper (read up on the the C++ extern "C" construct which will let you define functions that will not have the C++ symbol mangling applied to them). I can't comment on the automated tools like swig, I don't use them.

 

Having done the hard yards to write an AFV client, I really don't recommend trying to deal with the AFV internals in C. Most of the rest of a native voice-only client shouldn't be too bad except... for having to talk to the ATC client. I'm not sure how the AFV client currently does it (if it does at all), but if it needs Windows IPC, it's probably going to be quite hard to sort out.

[James Sandiford 1424826]

You can always join the VATSIM Dev Team by sending an email to vpdev(at)vatsim.net and offer yourself to build a native Linux client

 

 

Vatsim messed this transition up horribly, you have nothing to be proud of.

[Ross Carlson]

You can always join the VATSIM Dev Team by sending an email to vpdev(at)vatsim.net and offer yourself to build a native Linux client

 

 

Vatsim messed this transition up horribly, you have nothing to be proud of.

 

James, your post seems really out of place in this thread. Did you post in the wrong thread by mistake?

[Gary Oliver]

Vatsim messed this transition up horribly, you have nothing to be proud of.

 

Double the number of connections at nearly any time of day before AFV was released... yeah a real messed up transition.

 

Maybe you might want to accept you’re in a far too vocal minority, but the majority of sane members of the network are enjoying things....

 

Once you have removed ones head out of ones bottom maybe come back and have a sensible discussion.

 

Cheers

G

[Jonas Eberle]

I am reviving this thread just to say that https://github.com/pierr3/VectorAudio is now really usable and is there to solve the audio part on Linux/Mac.