CentOS Death in 2021

[Richard Gaskin]

Pi Digital wrote:

 > Ah, i see your POV now. You distinguish a difference between ‘runs on’
 > and ‘deploys on’. Where as I infer that there is no difference and
 > that ‘supports’ is as ‘system requirements’ or ‘supported systems’.

To me "runs on" and "deploys on" can only be the same thing when 
discussing a system like LiveCode, where the IDE is made from the same 
engine as a standalone.

According to at least one core team member, the distinction with 
"supported" is that they viewed it as "things the company is publicly 
committing to provide technical support resources for", which of course 
is a subset of "runs on".  Indeed, "supported" in that sense isn't even 
a technical consideration as much as a business one, arguably cause for 
replacing the word "supported" with something else that has no 
implications for business expense obligations.



 > The document is aimed at users of Livecode who, of course are
 > developers but, are also making use of the IDE. So, imho I would see
 > a need to have perhaps a separate part for each then. A runs on and
 > deploys to section.

I'm not opposed to the idea at all, but what circumstances would create 
a difference between the two for any GUI desktop platform, given that 
the LC IDE stacks are driven by the same engine that runs our stacks?



 > More than just runs on in fact. That infers that it can chug along on
 > with fits and starts. But a ‘system recommendation for development’.
 > And THEN a section for ‘systems supported for deployment’ or
 > ‘standalone system requirements’ to keep the same vernacular as the
 > IDE itself. With known issues covering both the IDE and Deployment as
 > two separate sections also.

Ah - that distinction makes solid sense to me, and we often see two sets 
of listings for sys reqs, "Minimum" and "Recommended".

For the IDE, this can be known, and would be helpful if provided.

For our applications it cannot be known by any author of a Release 
Notes, because they can't know what we're going to be doing with the 
engine.  I can make super-lean apps that fly and super-bloated apps that 
crawl, but I can't expect their company to provide guidance for me on 
either; the range of resource usage combinations is simply too vast, and 
being my work and not theirs they can't know what I'm doing.

But for the IDE, yes with two thumbs up to having separate "Minimum" and 
"Recommended" resource requirements listings.

Do I understand your request on that one?



 > And then the requirement for Linux to have these separate libraries
 > installed on BOTH the IDE machine AND the ‘end users’ Linux machine
 > running the standalone should be made all the more clearer. Perhaps
 > the ‘installation’ section should be separated entirely into the three
 > main platforms with Linux being given a little more care in referring
 > to each Linux distro in turn where needed.

Whether the dependencies are better handled if moved from "Requirements" 
to "Installation" I'll leave to them.  FWIW I've never encountered a 
desktop Linux system that could run a browser but not run LiveCode, so 
for me their guidance on that has proven consistently true.  Where more 
specific details are needed, their listing of required packages appears 
to be complete.



 > Back to my OP.
 > - What system build of Linux should I best install in Parallels
 > virtual and Server Remote Host for deployment should I run with?
 > Given the choices of potentially having LC IDE running as the ‘live’
 > software stack on the server itself (which is not the best way to run
 > it, but potentially a method that is usable for our purposes perhaps).

What is the benefit of running the LC IDE on a server, as opposed to a 
standalone?  Do you need a GUI there at all?

Either way, I believe Heriberto made a solid case yesterday for Ubuntu. 
As the most popular distro, it has more docs, tutorials, and community 
support, and more de facto testing.  It's also the leading choice for 
computer manufacturers shipping with Linux preinstalled, like Dell's XP 
line and similar from HP, Acer, and others.

Whether Ubuntu's fixed release schedule is a feature or a bug is a 
matter of taste, but personally I like knowing exactly how long I have 
with an OS version before I commit to rolling it out, and most admins I 
know do too.


- Which systems of Linux can we safely develop and test in?

For GUI installations, my experience supports the guidance LC Ltd 
provides in the Release Notes: if it can run a browser, it can run LC.

I've personally run LC on Ubuntu, Xubuntu, Lubuntu, Pop!_OS, Mint, 
Fedora, Debian, and a few others.


 > - And then, which systems of Linux can we safely deploy and run in?
 > And what are the known issues for both develop/test, and deploy/run?

In my experience all of the above plus Raspian, if you avoid a couple of 
known trouble spots with that older LC on Linux/ARM (menus crash, but 
other command UI elements like buttons work great so sometimes not an 
issue depending on the app).

I've run LC Server and faceless standalones on all the ones listed plus 
Ubuntu Core (both Intel and ARM), CentOS, and Enterprise SUSE.

I haven't read the LC Server Release Notes in a long time, but IIRC the 
guidance there reflects my personal experience.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com