|
Re: Clear Night - PEM Pro
Bill Long
Second run was 10"....
From: ap-gto@... on behalf of Bill Long bill@... [ap-gto]
Sent: Monday, February 19, 2018 7:39 PM To: ap-gto@... Subject: [ap-gto] Clear Night - PEM Pro 11.63 arc seconds of error in an AP1100...?
|
|
|
|
Re: INDI AP driver
Benoit Schillings
+1
On Mon, Feb 19, 2018 at 7:18 PM, Bill Long bill@... [ap-gto] <ap-gto@...> wrote:
|
|
|
|
Re: Clear Night - PEM Pro
Bill Long
Camera was set to 100,0000 ADU so had a saturated star in it, trying again with the value set to 30,000 and now my star isn't saturated.
From: ap-gto@... on behalf of Bill Long bill@... [ap-gto]
Sent: Monday, February 19, 2018 7:39 PM To: ap-gto@... Subject: [ap-gto] Clear Night - PEM Pro 11.63 arc seconds of error in an AP1100...?
|
|
|
|
Clear Night - PEM Pro
Bill Long
11.63 arc seconds of error in an AP1100...?
|
|
|
|
Re: INDI AP driver
Bill Long
Or spending large amounts of budget to purchase A-P gear for the purposes of research. Why not support that?
From: ap-gto@... on behalf of chris1011@... [ap-gto]
Sent: Monday, February 19, 2018 6:03 PM To: ap-gto@... Subject: Re: [ap-gto] INDI AP driver Joe, -----Original Message-----
From: 'Joseph Zeglinski' J.Zeglinski@... [ap-gto] To: ap-gto Sent: Mon, Feb 19, 2018 7:59 pm Subject: Re: [ap-gto] INDI AP driver Rolando,
Maybe the academics are too smart – as there is more “grant money” to be had for doing research in reinventing the wheel, than for buying stuff off-the-shelf.
Joe
From: chris1011@... [ap-gto]
Sent: Monday, February 19, 2018 8:47 PM
To: ap-gto@...
Subject: Re: [ap-gto] INDI AP driver
Marj and I attended a professional telescope conference about 5 years ago on Hawaii Island. The researchers were talking about developing their control systems and having grad students do the software. Problem is that those grad students go away after a short time and new ones replace them. All the work the previous ones did gets canned in the round file and the new guys start all over again. Of course they don't really know what they needed to do, so spent a lot of time "researching". During their presentations they would ask the attendees how to do some task, meanwhile in the back of the room sat Bob Denny who was frantically putting his hand up. "Hey guys, we've done all that already" he would shout. "I know what you guys need and I have the software for it". Do you think any of them would listen? Nah. Rolando
|
|
|
|
Re: INDI AP driver
Ray Gralak
You wrote:
Let me put it this way - When a typical person decides to make an app fromyou that *won't* enter their mind is "I'm going to code this in .NET." It justwon't. They're going to look for a C or C++ client library.things that are normal to the platform and culture they're operating in. Outside ofWindows, .NET and C# are very firmly not part of the picture or developer culture, I canassure you.No you can't assure me because I've seen and experienced otherwise. Businesses make decisions based on good business cases. Most grad students programming LINUX do so because that's all they have to work with and there is no real profit/loss that they have to worry about. Someone said listen to customers and do what they say. To do that blindly is bad advice IMHO. Yes, you should listen, but don't act unless it makes good business sense. Anyway, I think you are overlooking the obvious... the primary amateur Astronomy market has been developed with ASCOM for a long time. And because the ASCOM platform developers chose .Net for the platform most Astronomy based Windows applications have been coded in .Net for the last decade. Now, extrapolating... since there are many more ASCOM applications than INDI LINUX applications you should see that there many Astronomy-based .Net applications. Those applications could be ported to os/x and linux with Xamarin or other solutions much more quickly than redeveloping them from scratch. Yes because up until recently, ASCOM on Windows was the only game in townthere is a computer pro, and if the instructions for their mount/camera/focuser say"On a Windows PC, install ASCOM and our driver", that is just what they will do.As such, ASCOM has ubiquitous vendor support because *it has largely been the onlything around to support*.ASCOM and early astronomy applications targeted Windows because that's where the marketplace was and still is. Most of the best developers have targeted windows because that's the primary marketplace. -Ray Gralak Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/ap cc Author of PEMPro: http://www.ccdware.com Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver Author of PulseGuide: http://www.pulseguide.com Author of Sigma: http://www.gralak.com/sigma -----Original Message-----[ap- gto] <ap-gto@...> wrote:is windows,different. islanguageopen sourced, would compile cross platform, and would be completely virtuallyagnostic from a client's perspective (rest api + json payload is arestandard)No one outside of Windows cares about .NET and the only people who might tend to be Windows developers who are looking for easy ways to port theirexisting apps. People who operate on non-Windows platforms care about languagesthat they can easily take to other platforms and compile and debug there, be itLinux on Atom or FreeBSD on ARM64. Windows usually isn't part of that calculus, andyou that *won't* enter their mind is "I'm going to code this in .NET." It justwon't. They're going to look for a C or C++ client library. They're going to look forPython, Perl, Go, Java, or Rust bindings to those libraries. They will be looking forthings that are normal to the platform and culture they're operating in. Outside ofWindows, .NET and C# are very firmly not part of the picture or developer culture, I canassure you.windowsThe advantage is that the ASCOM api calls would be consistent for whatapps potentially ported to mac/linux. If the windows apps have to be don't thinkway you look at it the market for linux is small compared to windows andI would let the developers out there make that decision for themselves; I it's our place to make that decision. The tools should be made availableand as generic and open as possible; and people will chose to use them or not. Noone thought INDI would take off when it saw first light, but now users arewanting it and developers and vendors are providing for it. This should say something.Vendors and developers will either help stoke that fire, or decide to be a wetblanket. toI bet there are at least 100x more amateurs on ASCOM/windows than there is aosx/linux by making it as easy as possible (ie. An ASCOM api).Yes because up until recently, ASCOM on Windows was the only game in town computer pro, and if the instructions for their mount/camera/focuser say"On a Windows PC, install ASCOM and our driver", that is just what they will do.As such, ASCOM has ubiquitous vendor support because *it has largely been the onlything around to support*.
|
|
|
|
Re: INDI AP driver
ajynrynn@...
Hi Rolando,
Yes, a lot of projects get orphaned but many open source projects that started out in academia as student projects are now mainstream and living on. Linux itself started with Linus Torvald's personal quest for a free OS and is now part of the Android system. The hallmark of successful open source projects is a leader with vision and motivation. With good guidance and oversight, opensource projects live on and mature. In our own area of interest, I point to the Open PHD project. Look how far it has come since Craig Stark made the program open source! Ajay
|
|
|
|
Re: INDI AP driver
Roland Christen
Joe,
toggle quoted messageShow quoted text
Believe me, they are not getting paid much for their work. Some of the researchers have second jobs or are moonlighting to pay the rent. Rolando
-----Original Message-----
From: 'Joseph Zeglinski' J.Zeglinski@... [ap-gto] To: ap-gto Sent: Mon, Feb 19, 2018 7:59 pm Subject: Re: [ap-gto] INDI AP driver Rolando,
Maybe the academics are too smart – as there is more
“grant money” to be had for doing research in reinventing the wheel, than for
buying stuff off-the-shelf.
Joe
From: chris1011@... [ap-gto]
Sent: Monday, February 19, 2018 8:47 PM
To: ap-gto@...
Subject: Re: [ap-gto] INDI AP driver
Marj and I attended a professional telescope conference about 5 years ago on Hawaii Island. The researchers were talking about developing their control systems and having grad students do the software. Problem is that those grad students go away after a short time and new ones replace them. All the work the previous ones did gets canned in the round file and the new guys start all over again. Of course they don't really know what they needed to do, so spent a lot of time "researching". During their presentations they would ask the attendees how to do some task, meanwhile in the back of the room sat Bob Denny who was frantically putting his hand up. "Hey guys, we've done all that already" he would shout. "I know what you guys need and I have the software for it". Do you think any of them would listen? Nah. Rolando
|
|
|
|
Re: INDI AP driver
Joe Zeglinski
Rolando,
Maybe the academics are too smart – as there is more
“grant money” to be had for doing research in reinventing the wheel, than for
buying stuff off-the-shelf.
Joe
From: chris1011@... [ap-gto]
Sent: Monday, February 19, 2018 8:47 PM
To: ap-gto@...
Subject: Re: [ap-gto] INDI AP driver Marj and I attended a professional telescope conference about 5 years ago on Hawaii Island. The researchers were talking about developing their control systems and having grad students do the software. Problem is that those grad students go away after a short time and new ones replace them. All the work the previous ones did gets canned in the round file and the new guys start all over again. Of course they don't really know what they needed to do, so spent a lot of time "researching". During their presentations they would ask the attendees how to do some task, meanwhile in the back of the room sat Bob Denny who was frantically putting his hand up. "Hey guys, we've done all that already" he would shout. "I know what you guys need and I have the software for it". Do you think any of them would listen? Nah. Rolando
|
|
|
|
Re: INDI AP driver
ajynrynn@...
>However they know they hate Windows and will only embrace Linux and/or Mac.
>Personally I am rather agnostic towards operating systems. I hate them all equally.  Much needed humor for this thread!Ajay
|
|
|
|
Re: INDI AP driver
Joe Zeglinski
Hi Chris,
Now you have my curiosity up.
WHY do the academics have such a distaste for Windows – or is it Microsoft,
or is it still for Bill Gates?
Did Apple provide more funding or lucrative discounts than Microsoft?
If they are so buried in their own research, and don’t
care about such trivia as the OS – then who is brainwashing them to hate Windows
– or is it an academia “fraternity thing” of belonging to the ”right crowd”
?
There really shouldn’t be that much held against the OS
– so long as it does the intended job, and is universal, not requiring “special”
support.
Frankly, even though my own initial experiences included
a few years around SCO-XENIX, I might jump to LINUX someday, but can’t seem to
leave my Windows “comfort zone”. Don’t care which OS I use, so long as it
supports ALL my astro needs, without having to jump through APPS compatibility
hoops.
Joe
From: 'Christopher Erickson'
christopher.k.erickson@... [ap-gto]
Sent: Monday, February 19, 2018 7:39 PM
To: ap-gto@...
Subject: RE: [ap-gto] INDI AP driver "Actually,
they should care." Doesn't help much in my situation. Most scientists I deal with aren't computer experts and don't concern themselves with those kinds of secondary details that aren't directly related to their fundamental subject of research. They leave those kinds of irrelevant, "in the weeds" details to engineers and grad students. However they know they hate Windows and will only embrace Linux and/or Mac. Personally I am rather agnostic towards operating systems. I hate them all equally. -Christopher Erickson Observatory engineer Summit Kinetics Waikoloa, HI 96738 www.summitkinetics.com
|
|
|
|
Re: INDI AP driver
I remember those presentations too. LOL Welcome to my world.
On Feb 19, 2018 3:47 PM, "chris1011@... [ap-gto]" <ap-gto@...> wrote:
|
|
|
|
Re: INDI AP driver
Ray Gralak
No one outside of Windows cares about .NET and the only people who mightare tend to be Windows developers who are looking for easy ways to port theirexisting apps.If you say so! Let me put it this way - When a typical person decides to make an app fromyou that *won't* enter their mind is "I'm going to code this in .NET." It justwon't. They're going to look for a C or C++ client library. They're going to look forPython, Perl, Go, Java, or Rust bindings to those libraries. They will be looking forthings that are normal to the platform and culture they're operating in. Outside ofWindows, .NET and C# are very firmly not part of the picture or developer culture, I canassure you.I think you are overlooking the obvious... the primary amateur Astronomy market has been developed with ASCOM for a long time. And because the ASCOM platform developers chose .Net for the platform most Astronomy based Windows applications have been coded in .Net for the last decade. Now, extrapolating... since there are many more ASCOM applications than INDI LINUX applications you should see that there many Astronomy-based .Net applications. Those applications could be ported to os/x and linux with Xamarin or other solutions much more quickly than redeveloping them from scratch. Yes because up until recently, ASCOM on Windows was the only game in townthere is a computer pro, and if the instructions for their mount/camera/focuser say"On a Windows PC, install ASCOM and our driver", that is just what they will do.As such, ASCOM has ubiquitous vendor support because *it has largely been the onlything around to support*.ASCOM and early astronomy applications targeted Windows because that's where the marketplace was and still is. Most of the best developers have targeted windows because that's the primary marketplace. -Ray Gralak Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/ap cc Author of PEMPro: http://www.ccdware.com Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver Author of PulseGuide: http://www.pulseguide.com Author of Sigma: http://www.gralak.com/sigma -----Original Message-----[ap- gto] <ap-gto@...> wrote:is windows,different. islanguageopen sourced, would compile cross platform, and would be completely virtuallyagnostic from a client's perspective (rest api + json payload is arestandard)No one outside of Windows cares about .NET and the only people who might tend to be Windows developers who are looking for easy ways to port theirexisting apps. People who operate on non-Windows platforms care about languagesthat they can easily take to other platforms and compile and debug there, be itLinux on Atom or FreeBSD on ARM64. Windows usually isn't part of that calculus, andyou that *won't* enter their mind is "I'm going to code this in .NET." It justwon't. They're going to look for a C or C++ client library. They're going to look forPython, Perl, Go, Java, or Rust bindings to those libraries. They will be looking forthings that are normal to the platform and culture they're operating in. Outside ofWindows, .NET and C# are very firmly not part of the picture or developer culture, I canassure you.windowsThe advantage is that the ASCOM api calls would be consistent for whatapps potentially ported to mac/linux. If the windows apps have to be don't thinkway you look at it the market for linux is small compared to windows andI would let the developers out there make that decision for themselves; I it's our place to make that decision. The tools should be made availableand as generic and open as possible; and people will chose to use them or not. Noone thought INDI would take off when it saw first light, but now users arewanting it and developers and vendors are providing for it. This should say something.Vendors and developers will either help stoke that fire, or decide to be a wetblanket. toI bet there are at least 100x more amateurs on ASCOM/windows than there is aosx/linux by making it as easy as possible (ie. An ASCOM api).Yes because up until recently, ASCOM on Windows was the only game in town computer pro, and if the instructions for their mount/camera/focuser say"On a Windows PC, install ASCOM and our driver", that is just what they will do.As such, ASCOM has ubiquitous vendor support because *it has largely been the onlything around to support*.
|
|
|
|
Re: INDI AP driver
Roland Christen
Marj and I attended a professional telescope conference about 5 years ago on Hawaii Island. The researchers were talking about developing their control systems and having grad students do the software. Problem is that those grad students go away after a short time and new ones replace them. All the work the previous ones did gets canned in the round file and the new guys start all over again. Of course they don't really know what they needed to do, so spent a lot of time "researching". During their presentations they would ask the attendees how to do some task, meanwhile in the back of the room sat Bob Denny who was frantically putting his hand up. "Hey guys, we've done all that already" he would shout. "I know what you guys need and I have the software for it". Do you think any of them would listen? Nah.
toggle quoted messageShow quoted text
Rolando
-----Original Message-----
From: 'Christopher Erickson' christopher.k.erickson@... [ap-gto] To: ap-gto Sent: Mon, Feb 19, 2018 7:07 pm Subject: RE: [ap-gto] INDI AP driver "Actually, they should care." Doesn't help much in my situation. Most scientists I deal with aren't computer experts and don't concern themselves with those kinds of secondary details that aren't directly related to their fundamental subject of research. They leave those kinds of irrelevant, "in the weeds" details to engineers and grad students. However they know they hate Windows and will only embrace Linux and/or Mac. Personally I am rather agnostic towards operating systems. I hate them all equally. -Christopher Erickson Observatory engineer Summit Kinetics Waikoloa, HI 96738 www.summitkinetics.com -----Original Message----- From: ap-gto@... [mailto:ap-gto@...] Sent: Monday, February 19, 2018 11:09 AM To: ap-gto@... Subject: Re: [ap-gto] INDI AP driver > On Feb 19, 2018, at 2:28 PM, 'Christopher Erickson' christopher.k.erickson@... [ap-gto] gto@...> wrote: > > As for INDI, I don't really care if the Linux solution uses INDI or a ported version of ASCOM, or something else entirely. Linux is the magic word that my academic clients want to hear. Actually, they should care. INDI being designed and coded in ways that make it cross-platform is just one bonus. Keep in mind that the INDI client library is written in C++ and is able to be compiled on multiple OSes. Accordingly, there are bindings for other languages for it, such as Perl, Java, and Python. I'm sure if someone wanted to make Golang or Rust bindings, those can be created with a minima of fuss. This means that coding for the platform becomes more accessible to the undergrad/grad or hobbyist who is more used to non-Windows environs and languages. You don't find this with .Net, and if you can find it, it's probably a long and tortuous path that greatly detracts from the original goal of making astronomy apps. The point is is that INDI doesn't lock one down to a specific OS or language whether it's the server in the observatory, or on the remote clients. There's value in this true freedom of choice here. With ASCOM, you can potentially talk to it using multiple languages, but you still need to act against the ASCOM library which means you're still stuck with Windows as the OS you have to do it on. You're locked in to it, and you have to also be ok with all the other baggage that Windows brings with it. As for looking for a business case, I caution that this is a path that often sets one up to easily dismiss and carry on. INDI is the only true open and cross-platform (by design, mind you) control stack that we have. I think that hardware and app makers should take notice of this aspect and base part of their decision of whether or not to support INDI on the ideal that affording their customer more options in how they use their hardware is always better than the status quo of just "run ASCOM on Windows." To attract users, INDI must have capability. This capability is nurtured in a great part through hardware and app vendors providing for it and sometimes this has to happen altruistically and out of interest not just for the business case, but also to *further astronomy tech* in general. Otherwise, you just set yourself up for a chicken-or-egg situation if you look solely for a business case based on people using INDI now. /dale ------------------------------------ Posted by: Dale Ghent <daleg@...> ------------------------------------ To UNSUBSCRIBE, or for general information on the ap-gto list see http://groups.yahoo.com/group/ap-gto ------------------------------------ Yahoo Groups Links --- This email has been checked for viruses by AVG. http://www.avg.com ------------------------------------ Posted by: "Christopher Erickson" <christopher.k.erickson@...> ------------------------------------ To UNSUBSCRIBE, or for general information on the ap-gto list see http://groups.yahoo.com/group/ap-gto ------------------------------------ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/ap-gto/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/ap-gto/join (Yahoo! ID required) <*> To change settings via email: ap-gto-digest@... ap-gto-fullfeatured@... <*> To unsubscribe from this group, send an email to: ap-gto-unsubscribe@... <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
|
|
|
|
Re: INDI AP driver
Bill Long
I don't think this whole thread has anything to do with you justifying the position. This had everything to do with you dispelling a myth that you believed existed that clearly does not. From: ap-gto@... on behalf of 'Ray Gralak (Groups)' groups3@... [ap-gto]
Sent: Monday, February 19, 2018 1:53 PM
To: ap-gto@... Subject: RE: [ap-gto] INDI AP driver I think you are thinking of the full windows .net framework. .Net Core is
> -----Original Message-----
> From: ap-gto@... [mailto:ap-gto@...] > Sent: Monday, February 19, 2018 1:09 PM > To: ap-gto@... > Subject: Re: [ap-gto] INDI AP driver > > > > > > > On Feb 19, 2018, at 2:28 PM, 'Christopher Erickson' > christopher.k.erickson@... [ap-gto] wrote: > > > > As for INDI, I don't really care if the Linux solution uses INDI or a ported version of > ASCOM, or something else entirely. Linux is the magic word that my academic > clients want to hear. > > Actually, they should care. INDI being designed and coded in ways that make it > cross-platform is just one bonus. Keep in mind that the INDI client library is written in > C++ and is able to be compiled on multiple OSes. Accordingly, there are bindings > for other languages for it, such as Perl, Java, and Python. I'm sure if someone > wanted to make Golang or Rust bindings, those can be created with a minima of > fuss. This means that coding for the platform becomes more accessible to the > undergrad/grad or hobbyist who is more used to non-Windows environs and > languages. You don't find this with .Net, and if you can find it, it's probably a long and > tortuous path that greatly detracts from the original goal of making astronomy apps. > > The point is is that INDI doesn't lock one down to a specific OS or language whether > it's the server in the observatory, or on the remote clients. There's value in this true > freedom of choice here. With ASCOM, you can potentially talk to it using multiple > languages, but you still need to act against the ASCOM library which means you're > still stuck with Windows as the OS you have to do it on. You're locked in to it, and you > have to also be ok with all the other baggage that Windows brings with it. > > As for looking for a business case, I caution that this is a path that often sets one up > to easily dismiss and carry on. INDI is the only true open and cross-platform (by > design, mind you) control stack that we have. I think that hardware and app makers > should take notice of this aspect and base part of their decision of whether or not to > support INDI on the ideal that affording their customer more options in how they use > their hardware is always better than the status quo of just "run ASCOM on Windows." > To attract users, INDI must have capability. This capability is nurtured in a great part > through hardware and app vendors providing for it and sometimes this has to happen > altruistically and out of interest not just for the business case, but also to *further > astronomy tech* in general. Otherwise, you just set yourself up for a chicken-or-egg > situation if you look solely for a business case based on people using INDI now. > > /dale > >
|
|
|
|
Re: INDI AP driver
"Actually, they should care."
toggle quoted messageShow quoted text
Doesn't help much in my situation. Most scientists I deal with aren't computer experts and don't concern themselves with those kinds of secondary details that aren't directly related to their fundamental subject of research. They leave those kinds of irrelevant, "in the weeds" details to engineers and grad students. However they know they hate Windows and will only embrace Linux and/or Mac. Personally I am rather agnostic towards operating systems. I hate them all equally. -Christopher Erickson Observatory engineer Summit Kinetics Waikoloa, HI 96738 www.summitkinetics.com
-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...] Sent: Monday, February 19, 2018 11:09 AM To: ap-gto@... Subject: Re: [ap-gto] INDI AP driver On Feb 19, 2018, at 2:28 PM, 'Christopher Erickson'christopher.k.erickson@... [ap-gto] <ap-gto@...> wrote: ported version of ASCOM, or something else entirely. Linux is the magic word that my academic clients want to hear. Actually, they should care. INDI being designed and coded in ways that make it cross-platform is just one bonus. Keep in mind that the INDI client library is written in C++ and is able to be compiled on multiple OSes. Accordingly, there are bindings for other languages for it, such as Perl, Java, and Python. I'm sure if someone wanted to make Golang or Rust bindings, those can be created with a minima of fuss. This means that coding for the platform becomes more accessible to the undergrad/grad or hobbyist who is more used to non-Windows environs and languages. You don't find this with .Net, and if you can find it, it's probably a long and tortuous path that greatly detracts from the original goal of making astronomy apps. The point is is that INDI doesn't lock one down to a specific OS or language whether it's the server in the observatory, or on the remote clients. There's value in this true freedom of choice here. With ASCOM, you can potentially talk to it using multiple languages, but you still need to act against the ASCOM library which means you're still stuck with Windows as the OS you have to do it on. You're locked in to it, and you have to also be ok with all the other baggage that Windows brings with it. As for looking for a business case, I caution that this is a path that often sets one up to easily dismiss and carry on. INDI is the only true open and cross-platform (by design, mind you) control stack that we have. I think that hardware and app makers should take notice of this aspect and base part of their decision of whether or not to support INDI on the ideal that affording their customer more options in how they use their hardware is always better than the status quo of just "run ASCOM on Windows." To attract users, INDI must have capability. This capability is nurtured in a great part through hardware and app vendors providing for it and sometimes this has to happen altruistically and out of interest not just for the business case, but also to *further astronomy tech* in general. Otherwise, you just set yourself up for a chicken-or-egg situation if you look solely for a business case based on people using INDI now. /dale ------------------------------------ Posted by: Dale Ghent <daleg@...> ------------------------------------ To UNSUBSCRIBE, or for general information on the ap-gto list see http://groups.yahoo.com/group/ap-gto ------------------------------------ Yahoo Groups Links --- This email has been checked for viruses by AVG. http://www.avg.com
|
|
|
|
Re: INDI AP driver
Dale Ghent
On Feb 19, 2018, at 4:53 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] <ap-gto@...> wrote:No one outside of Windows cares about .NET and the only people who might are tend to be Windows developers who are looking for easy ways to port their existing apps. People who operate on non-Windows platforms care about languages that they can easily take to other platforms and compile and debug there, be it Linux on Atom or FreeBSD on ARM64. Windows usually isn't part of that calculus, and forcing .NET or any MS-tinged tech on people will just estrange potential developers on these other platforms even more. Let me put it this way - When a typical person decides to make an app from scratch on a non-Windows platform, the first thing that I can guarantee you that *won't* enter their mind is "I'm going to code this in .NET." It just won't. They're going to look for a C or C++ client library. They're going to look for Python, Perl, Go, Java, or Rust bindings to those libraries. They will be looking for things that are normal to the platform and culture they're operating in. Outside of Windows, .NET and C# are very firmly not part of the picture or developer culture, I can assure you. The advantage is that the ASCOM api calls would be consistent for windowsI would let the developers out there make that decision for themselves; I don't think it's our place to make that decision. The tools should be made available and as generic and open as possible; and people will chose to use them or not. No one thought INDI would take off when it saw first light, but now users are wanting it and developers and vendors are providing for it. This should say something. Vendors and developers will either help stoke that fire, or decide to be a wet blanket. I bet there are at least 100x more amateurs on ASCOM/windows thanYes because up until recently, ASCOM on Windows was the only game in town that's easy to for Joe or Jane Astronomer set up. Not every amateur out there is a computer pro, and if the instructions for their mount/camera/focuser say "On a Windows PC, install ASCOM and our driver", that is just what they will do. As such, ASCOM has ubiquitous vendor support because *it has largely been the only thing around to support*. /dale
|
|
|
|
Re: INDI AP driver
Ray Gralak
I think you are thinking of the full windows .net framework. .Net Core is
toggle quoted messageShow quoted text
different. An ASCOM .Net Core using a Rest api server would not be based on windows, is open sourced, would compile cross platform, and would be completely language agnostic from a client's perspective (rest api + json payload is virtually standard) The advantage is that the ASCOM api calls would be consistent for windows apps potentially ported to mac/linux. If the windows apps have to be completely rewritten for INDI, they won't likely be ported. No matter what way you look at it the market for linux is small compared to windows and even osx. I bet there are at least 100x more amateurs on ASCOM/windows than INDI/linux+osx so I think you would want to woo Windows apps developers to osx/linux by making it as easy as possible (ie. An ASCOM api). -Ray Gralak Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/ap cc Author of PEMPro: http://www.ccdware.com Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver Author of PulseGuide: http://www.pulseguide.com Author of Sigma: http://www.gralak.com/sigma
-----Original Message-----ported version of ASCOM, or something else entirely. Linux is the magic word that myacademic clients want to hear.make it cross-platform is just one bonus. Keep in mind that the INDI clientlibrary is written in C++ and is able to be compiled on multiple OSes. Accordingly, there arebindings for other languages for it, such as Perl, Java, and Python. I'm sure ifsomeone wanted to make Golang or Rust bindings, those can be created with a minimaof fuss. This means that coding for the platform becomes more accessible tothe undergrad/grad or hobbyist who is more used to non-Windows environs andprobably a long and tortuous path that greatly detracts from the original goal of makingastronomy apps. language whether it's the server in the observatory, or on the remote clients. There'svalue in this true freedom of choice here. With ASCOM, you can potentially talk to it usingmultiple languages, but you still need to act against the ASCOM library which meansyou're still stuck with Windows as the OS you have to do it on. You're locked into it, and you have to also be ok with all the other baggage that Windows brings with it.often sets one up to easily dismiss and carry on. INDI is the only true open andcross-platform (by design, mind you) control stack that we have. I think that hardware andapp makers should take notice of this aspect and base part of their decision ofwhether or not to support INDI on the ideal that affording their customer more options inhow they use their hardware is always better than the status quo of just "run ASCOM onWindows." To attract users, INDI must have capability. This capability is nurturedin a great part through hardware and app vendors providing for it and sometimes this hasto happen altruistically and out of interest not just for the business case, butalso to *further astronomy tech* in general. Otherwise, you just set yourself up for achicken-or-egg situation if you look solely for a business case based on people usingINDI now.
|
|
|
|
Re: INDI AP driver
Dale Ghent
On Feb 19, 2018, at 2:28 PM, 'Christopher Erickson' christopher.k.erickson@... [ap-gto] <ap-gto@...> wrote:Actually, they should care. INDI being designed and coded in ways that make it cross-platform is just one bonus. Keep in mind that the INDI client library is written in C++ and is able to be compiled on multiple OSes. Accordingly, there are bindings for other languages for it, such as Perl, Java, and Python. I'm sure if someone wanted to make Golang or Rust bindings, those can be created with a minima of fuss. This means that coding for the platform becomes more accessible to the undergrad/grad or hobbyist who is more used to non-Windows environs and languages. You don't find this with .Net, and if you can find it, it's probably a long and tortuous path that greatly detracts from the original goal of making astronomy apps. The point is is that INDI doesn't lock one down to a specific OS or language whether it's the server in the observatory, or on the remote clients. There's value in this true freedom of choice here. With ASCOM, you can potentially talk to it using multiple languages, but you still need to act against the ASCOM library which means you're still stuck with Windows as the OS you have to do it on. You're locked in to it, and you have to also be ok with all the other baggage that Windows brings with it. As for looking for a business case, I caution that this is a path that often sets one up to easily dismiss and carry on. INDI is the only true open and cross-platform (by design, mind you) control stack that we have. I think that hardware and app makers should take notice of this aspect and base part of their decision of whether or not to support INDI on the ideal that affording their customer more options in how they use their hardware is always better than the status quo of just "run ASCOM on Windows." To attract users, INDI must have capability. This capability is nurtured in a great part through hardware and app vendors providing for it and sometimes this has to happen altruistically and out of interest not just for the business case, but also to *further astronomy tech* in general. Otherwise, you just set yourself up for a chicken-or-egg situation if you look solely for a business case based on people using INDI now. /dale
|
|
|
|
Re: INDI AP driver
I apologize for the "arrogant" comment. Most of the
academics I work with are certainly not arrogant in general but when it comes to
Macs, Linux and Windows, I believe the biases are based a bit more in
academic cultural pressure than on objective reasoning. I could have
used a better word than "arrogant."
Software licensing costs, especially ones based on annual
subscriptions, are dreadfully unpopular with academics, where grants and other
capital funds can buy big stuff but tiny operational budgets often can't
stretch to cover expensive subscription renewals along with
salaries.
-Christopher Erickson
Observatory engineer Summit Kinetics
From: ap-gto@... [mailto:ap-gto@...] Sent: Monday, February 19, 2018 6:46 AM To: ap-gto@... Subject: Re: [ap-gto] INDI AP driver Your technical points are all excellent.
For AP a business case to be made is that competitors are offering Linux
drivers. Many planet hunting farms use Paramounts. Large robotic telescope
networks use Linux. For them the savings in windows OS licensing fees are huge.
I see a business opportunity for AP. The increase in usage and mind-share, as was the
case when PHD became Open PHD, is something to look forward to.
As an academic, albeit at a non-research institution, I think the comment
on "certainly arrogant human bias" was unnecessary. "Possible ignorant human
bias" may have been enough. I am not defending any arrogant academics out there.
I've met a few in my days. In this case the bias is not uninformed. The
cost and stability of Linux that you point out are the bases for that
discriminating view.
Respecfully, Ajay
|
|
|
