CentOS Death in 2021
ambassador at fourthworld.com
Wed Dec 16 12:34:50 EST 2020
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.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode