Date   

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:
 

Or spending large amounts of budget to purchase A-P gear for the purposes of research. Why not support that?




From: ap-gto@... <ap-gto@...> on behalf of chris1011@... [ap-gto] <ap-gto@...>
Sent: Monday, February 19, 2018 6:03 PM
To: ap-gto@...
Subject: Re: [ap-gto] INDI AP driver
 
 

Joe,

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] <ap-gto@...>
To: ap-gto <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: 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,

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

Ray Gralak
 

You wrote:

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.
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 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*.
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-----
From: ap-gto@... [mailto:ap-gto@...]
Sent: Monday, February 19, 2018 4:35 PM
To: ap-gto@...
Subject: Re: [ap-gto] INDI AP driver





On Feb 19, 2018, at 4:53 PM, 'Ray Gralak (Groups)' groups3@...
[ap-
gto] <ap-gto@...> wrote:

I think you are thinking of the full windows .net framework. .Net Core
is
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)
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
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 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 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).
Yes 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

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,

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

Christopher Erickson
 

I remember those presentations too. LOL

Welcome to my world.


-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Feb 19, 2018 3:47 PM, "chris1011@... [ap-gto]" <ap-gto@...> wrote:


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



-----Original Message-----
From: 'Christopher Erickson' christopher.k.erickson@gmail.com [ap-gto] <ap-gto@...>
To: ap-gto <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@gmail.com [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@gmail.com>
------------------------------------

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@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
ap-gto-unsubscribe@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/




Re: INDI AP driver

Ray Gralak
 

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.
If you say so!

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.
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 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*.
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-----
From: ap-gto@... [mailto:ap-gto@...]
Sent: Monday, February 19, 2018 4:35 PM
To: ap-gto@...
Subject: Re: [ap-gto] INDI AP driver





On Feb 19, 2018, at 4:53 PM, 'Ray Gralak (Groups)' groups3@...
[ap-
gto] <ap-gto@...> wrote:

I think you are thinking of the full windows .net framework. .Net Core
is
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)
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
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 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 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).
Yes 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

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.

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
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-----
> 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

Christopher Erickson
 

"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] <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

------------------------------------
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:

I think you are thinking of the full windows .net framework. .Net Core is
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)
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 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 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 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).
Yes 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
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-----
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] <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

Dale Ghent
 

On Feb 19, 2018, at 2:28 PM, 'Christopher Erickson' christopher.k.erickson@... [ap-gto] <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

Christopher Erickson
 

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
Waikoloa, HI 96738
www.summitkinetics.com
 



From: ap-gto@... [mailto:ap-gto@...]
Sent: Monday, February 19, 2018 6:46 AM
To: ap-gto@...
Subject: Re: [ap-gto] INDI AP driver

Chris, 

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

Virus-free. www.avg.com