Livecode server UNIX version (not Linux).

[Heriberto Torrado]

Hi Richard,


Although I love UNIX, I think this is a much better point.
Looking at the feedback comments I have realized that porting Livecode 
to BSD may not be worth it.

However, I think it is critical for our community to be able to run 
Livecode scripting on IOT devices.

IOT and Edge computing is the future (and the present).

I dare to say that Livecode is a much simpler language for IOT than 
Python (although this is a personal opinion).

If you learn Livecode you kill five birds with one stone:
Desktop, Mobile, Scripting, Web and Server development.

Have you tried developing desktop or mobile applications with Python? It 
is a tremendous pain.

We need a much wider community to be able to extend Livecode to all areas.

Can you imagine Livecode as a popular option on most the important job 
posting sites?

I think the first step would be to have a working version of Livecode 
server for Raspberry.

Livecode currently compiles for many ARM versions.

How difficult could it be to adapt Livecode Server to these versions?


On 10/28/20 11:06 PM, Richard Gaskin via use-livecode wrote:
> Heriberto Torrado wrote:
>
> > So, here is my idea: What about to create non official versions of
> > Livecode server (for scripting purposes) for other platforms not yet
> > supported?
> > I think it could be good for RunRev: They won't have to work
> > supporting those versions and Livecode language will spread to other
> > fields.
> >
> > What do you guys think? Do you think we'll have enough manpower into
> > our community to do that?
>
> Raspberry Pi, w/ Raspbian or other Debian-based Linux (Linux ARM).
>
> Home servers, school labs, IoT, and so much more - all currently lost 
> to us by not having a build for that engine.
>
> The last build was an experiment done by a team member no longer with 
> the company, for LC v7.1.
>
> If you could update the Server edition to v9.6 we could at least have 
> a modern version to work with for faceless applications, and any 
> remaining work for the GUI side would likely be relatively small 
> (certainly smaller than one person trying to knock it all off by 
> themselves).
>