* Native version for linux

[rcpettit]

Would love to see a native version of FH for linux so you don't need wine.

[NickWalker]

I guess it would take years of work for CP to produce a version for linux, so there is pretty much no chance of this happening I think.

[tatewise]

There are several existing Wish List entries for Family Historian versions for various OS including Apple Mac, Android, iPhone/iPad & Linux/Wine that you can Vote for!
Just search the Wish List for the word version.
See thread Version for Linux operating System (10898) and Family Historian on Mac, Linux, iOS, Android etc.

[Gary_G]

As a Mac user, my opinion may come as a surprise. I would be careful what you wish for.

I've seen RootsMagic try to create a Mac version by cross-compiling their Windows code and advertising it as a "native" Mac version. It really didn't turn out well and has been responsible for many fellow "refugees" fleeing to FH7.

Having worked with cross-compilers in the aerospace industry, I know first-hand just much extra work is involved in properly validating cross-compiled code. It can do some very weird things, because the target platform sometimes has vastly different interface requirements. Trying to seamlessly accommodate those is a real headache.

Also; the cost of developing and maintaining a truly native version for each target platform is very expensive.

It's unbelievably difficult to make a buck in the software world these days, especially for packages aimed at the consumer market price-point. So; I doubt Calico Pie will look at either option in the near future.

[AdrianBruce]

... Having worked with cross-compilers in the aerospace industry, I know first-hand just much extra work is involved in properly validating cross-compiled code. It can do some very weird things, because the target platform sometimes has vastly different interface requirements. ...

Thanks Gary - it's interesting - as in the apocryphal Chinese curse of "May you live in interesting times..." I had this vague idea that cross-compiled code was the way to do this sort of thing. However, I had no concept of the gotchas involved. The converse of my vague idea is that I have had extensive experience of testing mainframe software and I really appreciate the difficulties in creating thorough testing routines. And that was pretty much without the vagaries of a user interface because I'm referring to either batch systems or systems with a very limited, script-based UI. Those were big scripts that I know came nowhere near testing more than the 20% of the system that was used 80% of the time.

[ColeValleyGirl]

Closing this as it's covered by an existing wish list item.