Re: CentOS Death in 2021
Richmond wrote: >On 16.12.20 2:14, Richard Gaskin via use-livecode wrote: >> Richmond wrote: >> > Well . . . they could install a later version of Ubuntu (takes >> > about 30-120 minutes) and build and test on that version. >> > >> > Surely not that arduous. >>... >> How familiar are you with the LC build system in Edinburgh? > > I am not familiar at all. > > But, having built an LC version for Linux it can then be tested on > a recent Linux distro. It once seemed that simple to me too. Mark Weider handled that very well this afternoon: http://lists.runrev.com/pipermail/use-livecode/2020-December/262712.html -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: CentOS Death in 2021
Sean - This thread began with a concern over how Linux compatibility is described in the Release Notes. I proposed a solution, but it didn't resonate. Perhaps a different approach may work: The audience for the Release Notes is developers, and what developers need to know is where LiveCode the application can be deployed. Any consideration about specific distros the company provides technical support for is arguably inappropriate in Release Notes altogether. First, technical support obligations are better described in the license offer. And second,they don't apply at all with Community Edition where the company has no technical support obligations. So... Since what we want to know is on which Linux distros LiveCode is known to run well on, would replacing "support" with "runs on" suffice? Of course we may touch up a few other sentence so it flows nicely, but do I understand correctly that the concern is to know where LC runs? If this suggestion doesn't cover what you're looking for, what would you prefer to see there? -- Richard Gaskin Fourth World Systems ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Slow performance on Big Sur
I had my client try it. Adding "wait 0 milliseconds" after a "go card" didn't make any difference really. The first four card changes were pretty fast, and after that it got slower and slower with each subsequent card change. I was watching her screen remotely but I couldn't see it due to how remote viewing works, but she said the redraw was quite noticeable. On 12/14/20 4:45 PM, merakosp via use-livecode wrote: Hello all, Does adding a after the command make any difference? Cheers, Panos -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: CentOS Death in 2021
I am not familiar at all. But, having built an LC version for Linux it can then be tested on a recent Linux distro. On 16.12.20 2:14, Richard Gaskin via use-livecode wrote: Richmond wrote: > Well . . . they could install a later version of Ubuntu (takes about > 30-120 minutes) and build and test on that version. > > Surely not that arduous. Exactly how sure are you? What they need to do is more than what customers need to do. How familiar are you with the LC build system in Edinburgh? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.com http://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: CentOS Death in 2021
It’s this kind of rhetoric that drive me to madness and then getting a used of being abusive as I defend what I’ve said. Richard, there is no need as you have clearly misinterpreted practically everything I said in an effort to get some kind of oneupmanship. >> On 16 Dec 2020, at 01:00, Richard Gaskin via use-livecode >> wrote: >> >> Pi Digital wrote: >> >> But that does not seem to correlate to the way it is for MacOS or Win. >> Are you saying they compile from all of those versions of MacOS and >> Win they reference to supporting. > > Mac and Windows are each made by a single organization, with specs defining > compatibility. > > "Linux" isn't an OS per se, it's a family of OSes, where the one thing they > all have in common is some form of the Linux kernel. Show Quoted Content >> On 16 Dec 2020, at 01:00, Richard Gaskin via use-livecode >> wrote: >> >> Pi Digital wrote: >> >> But that does not seem to correlate to the way it is for MacOS or Win. >> Are you saying they compile from all of those versions of MacOS and >> Win they reference to supporting. > > Mac and Windows are each made by a single organization, with specs defining > compatibility. > > "Linux" isn't an OS per se, it's a family of OSes, where the one thing they > all have in common is some form of the Linux kernel. Debian is Debian. Ubuntu is Ubuntu. Red hat is red hat. Blah blah. This is not my issue. Get the net. >> When reading about LiveCode support, to me it doesn’t matter if it >> is LC Ltd or the LC app. The two are pretty much interchangeable. > > One is a business, the other is a technology stack. The difference may not > matter to you, but it matters to them, and understandably so... > Point entirely missed! We are wholly talking about its mention in the release notes and that the ambiguation is not made evident and can ONLY be understood in the context of a release note under the heading of OS support that it refers to the support by the software of a given OS. Sheesh, I’m surprised I have to spell this out to you. Why do you pick on me as if, in this instance, I am trying to criticise LC (Ltd) in any way. > >> ...the release notes are written SPECIFICALLY for LC the product, not >> in reference to the company. > > Clearly I agree that the wording in the Release Notes can too easily give > that impression, which is why I submitted the enhancement request to clarify > it: > https://quality.livecode.com/show_bug.cgi?id=23035 > > >> I cannot see where this inference is coming from. > > It is not an inference. I'm familiar with qualifiers like "might be", and use > them liberally. I did not use a qualifier here, because in this case I'm > drawing from direct conversation with a key member of the core team. > > The explanation I conveyed to you was given to me a while back by Dr Peter > Brett in one of my ongoing Community Liaison meetings I have with the company. Show Quoted Content > >> ...the release notes are written SPECIFICALLY for LC the product, not >> in reference to the company. > > Clearly I agree that the wording in the Release Notes can too easily give > that impression, which is why I submitted the enhancement request to clarify > it: > https://quality.livecode.com/show_bug.cgi?id=23035 > > >> I cannot see where this inference is coming from. > > It is not an inference. I'm familiar with qualifiers like "might be", and use > them liberally. I did not use a qualifier here, because in this case I'm > drawing from direct conversation with a key member of the core team. > > The explanation I conveyed to you was given to me a while back by Dr Peter > Brett in one of my ongoing Community Liaison meetings I have with the company. PB hasn’t worked there in a while so I’m guessing that conversation has disappeared into obscurity. > > This is why I wrote: "...cited Mark Weider. He and I have each had > conversations with the core team on this, and what he wrote is correct." > > I have no reason to make this up. When I take time to write to you it's > because I'm doing my best to provide you with the best information I have Misunderstood as it is. > >> Basically put, if they can’t build it in, for example, Ubuntu 20, then >> it is not supported fully because of some minor/major issue. > > Have you considered the possibility that not everything in the build system > is made in LiveCode? I know all this so yes it’s not only considered but fully appreciated. This is not a complaint. It’s a situation I find myself facing with legitimate questions around what I should do best case for the future. > > Funny thing is, those of us who use LiveCode on Linux daily are the least > bothered by these support commitment things. > > Let our experience be of help where it can: LiveCode runs well on Ubuntu > 18.04 and Ubuntu 20.04, with the exceptions Panos noted earlier. And PDF rendering as I noted earlier, which is my main concern along with security of up to
Re: CentOS Death in 2021
Pi Digital wrote: > But that does not seem to correlate to the way it is for MacOS or Win. > Are you saying they compile from all of those versions of MacOS and > Win they reference to supporting. Mac and Windows are each made by a single organization, with specs defining compatibility. "Linux" isn't an OS per se, it's a family of OSes, where the one thing they all have in common is some form of the Linux kernel. Lots of combinations are possible, from distros made for tiny IoT devices to clusters of supercomputers, and just about everything in between. Thinking about the wide open world of Linux in the same terms one things about monolithic OSes made by single companies for narrowly-defined hardware can lead to a wide range of issues. Here, the core issue is expectations management. Personally, I find this guidance very useful, and is more succinct than I've seen from other Linux software vendors: The requirements for GUI functionality are also required by Firefox and Chrome, so if your Linux distribution runs one of those, it will run LiveCode. > When reading about LiveCode support, to me it doesn’t matter if it > is LC Ltd or the LC app. The two are pretty much interchangeable. One is a business, the other is a technology stack. The difference may not matter to you, but it matters to them, and understandably so: LiveCode-the-software runs on such a wide range of Linux systems it would be impractical for the folks at LiveCode-the-company to commit support resources for them all. So while a good many of us enjoy running LiveCode-the-software on anything we get our hands on, we respect that LiveCode-the-company isn't in a position to provide guidance if our choices don't line up with the systems they've chosen to support. > ...the release notes are written SPECIFICALLY for LC the product, not > in reference to the company. Clearly I agree that the wording in the Release Notes can too easily give that impression, which is why I submitted the enhancement request to clarify it: https://quality.livecode.com/show_bug.cgi?id=23035 > I cannot see where this inference is coming from. It is not an inference. I'm familiar with qualifiers like "might be", and use them liberally. I did not use a qualifier here, because in this case I'm drawing from direct conversation with a key member of the core team. The explanation I conveyed to you was given to me a while back by Dr Peter Brett in one of my ongoing Community Liaison meetings I have with the company. This is why I wrote: "...cited Mark Weider. He and I have each had conversations with the core team on this, and what he wrote is correct." I have no reason to make this up. When I take time to write to you it's because I'm doing my best to provide you with the best information I have. > Basically put, if they can’t build it in, for example, Ubuntu 20, then > it is not supported fully because of some minor/major issue. Have you considered the possibility that not everything in the build system is made in LiveCode? It's quite a beast they have there, compiling on each platform, shuffling the packages around to build installers, zips, and DMGs, each containing engines for multiple platforms. A great many components in the long tool chain used to build a LiveCode installer are not written in LiveCode. Each has their own dependencies, and changing one part sometimes means changing others in an intricate ripple effect. Funny thing is, those of us who use LiveCode on Linux daily are the least bothered by these support commitment things. Let our experience be of help where it can: LiveCode runs well on Ubuntu 18.04 and Ubuntu 20.04, with the exceptions Panos noted earlier. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Secure connection to server
A little while ago in this forum we were alerted to the fact that LC direct connection to a remote database not using SSL was a security hole. This also applies to managing Mailman lists on a remote server. After a steep (re-)learning curve with the various technologies, I now have a working method in place for both mysql and Mailman connections, using php as middleware and posting via curl in a shell script. But it is sooo slooow. Direct connection downloaded an sql query in a fraction of a second. It now takes over a second. This is acceptable (barely) for an isolated call, but I sometimes need to make a sequence of posts. As I understand it, the slowness is due to the time required to establish the secure connection, not an LC problem. For example establishing an ssh connection in Terminal is even slower; but once established an ssh session is super fast. Similarly curl will reuse authentication credentials within a shell session, so I aggregate as many calls as I can with a single shell script before using shell(myscript), and this definitely helps. What I would like to do however is use LC server as the middleware: I could then process the required data on the server side; I could not contemplate using php to do this. I suspect the LC post command uses curl under the hood, but I also suspect each post call would create its own session. I don’t think it is possible to establish a single session to talk sequentially to lcserver; if so this would be too slow. Am I correct? Actually I guess I could just use my present method using curl and shell() instead of post, but addressed to an .lc script instead of .php? Or is there a whole better way to do what I want? Neville Smythe ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: CentOS Death in 2021
Richmond wrote: > Well . . . they could install a later version of Ubuntu (takes about > 30-120 minutes) and build and test on that version. > > Surely not that arduous. Exactly how sure are you? What they need to do is more than what customers need to do. How familiar are you with the LC build system in Edinburgh? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: CentOS Death in 2021
Well . . . they could install a later version of Ubuntu (takes about 30-120 minutes) and build and test on that version. Surely not that arduous. Best, Richmond. On 15.12.20 19:38, Mark Wieder via use-livecode wrote: On 12/15/20 3:48 AM, Richmond via use-livecode wrote: 2. Stir up trouble. Personally I think that LiveCode central are being a bit @#$%^&* claiming that LiveCode is cross-platform and not saying they support more recent versions than Ubuntu 16.04 and so on. And stirring up trouble means that I think they deserve a collective kick in the source-code for that. I may be in the minority on my opinion on this, and judging from the feedback I expect from this post that may be an understatement, but... I think the team is correct in this. Support means more than "we think this works". Since they currently build and test each released version on an older linux distro, they can't really claim to "support" later versions, even though we can empirically verify that there is essentially no difference when running LC on other/later linuxes. Claiming support would mean dedicating resources to changing the build process, verifying that the resulting build performed to spec on whatever linux version, and also on an ongoing basis dedicating support team resources to whatever issues may arise on the newly officially supported platforms. And at present there's very little ROI for making these changes. Even the modifications that a few of us do contribute require redirecting company resources to verify (or not) before merging into the corpus of releasable code, and with the current worldwide situation I doubt there's a lot of free time to squeeze into redirection from actual revenue-producing streams. Since Ubuntu's EOL date is coming up in the next few months, I expect that the build platform may change soon. But since I can compile from source here on linux mint 20 (Ubuntu based) (as long as I modify the gyp file as in my PR) I don't expect major hiccups nor any major expense in team resources from this migration. 3. As far as I can see (probably not very far), there is no difference in functionality between Xubuntu 16.04 and 20.10; See above, but yes, I agree. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: CentOS Death in 2021
Thanks Panos. My main concern of late has been the PDF output font rendering in CentOS and I am hoping that it will be better in Ubuntu or another distro. But I’m guessing I’m going to have to do a whole heap of testing to find out. Sean Cole Pi Digital > On 15 Dec 2020, at 09:24, merakosp via use-livecode > wrote: > > Hello Sean, > > Off the top of my head, the main Linux issues that are currently unresolved > are: > > 1. The player object is broken on all Linux distros. You might be able to > workaround this by using shell commands with mplayer. > > 2. The browser widget is broken in most Linux distros. It might work for > just displaying a webpage, but not for typing into input fields of the > webpage. I am not sure if there is a workaround for this. > > 3. Also, you might experience window layering problems with some Linux > window manager (e.g. Cinnamon). > > Hope this helps, > Panos > -- > >> On Tue, 15 Dec 2020 at 10:42, Pi Digital via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> >> >>> On 15 Dec 2020, at 02:52, Richard Gaskin via use-livecode < >> use-livecode@lists.runrev.com> wrote: >>> >>> As Mark Weider noted, the "official" support is merely a reflection of >> their build system, and it relies on a version of Ubuntu still actively >> getting security updates. >> >> That doesn’t seem to be stated or inferred in the release notes. It’s >> under the heading ‘Platform Support’ which infers, like ‘System >> Requirements’ might, “This is what it will run on”. Indeed, under the >> heading it states: >> The engine supports a variety of operating systems and versions. This >> section describes the platforms that we ensure the engine runs on without >> issue (although in some cases with reduced functionality). >> >> >> Then under Linux it states: >> LiveCode supports the following Linux distributions, on 32-bit or >> 64-bit Intel/AMD or compatible processors: Ubuntu 14.04 and 16.04 Fedora 23 & 24 Debian 7 (Wheezy) and 8 (Jessie) [server] CentOS 7 [server] >> >> >> Then lists the Core and ‘optional’ GUI feature requirements. None of this >> states or infers that >=Ubuntu 18, >=Fedora 25, >=Debian 9 or >=CentOS 8. >> >> So we are left assuming that these unlisted platforms/versions, much like >> macOS 10.16, is “Unsupported”! Hence my initial question/request for >> community knowledge/experience. I’m not seeking to stir up trouble (for a >> change). I’m seeking understanding and wisdom. If LC is Not Supported on >> later builds, what aspects do not function in your (plural, ie, everyones) >> experiences. >> >> Because LC write “This section describes the platforms that we ensure the >> engine runs on without issue”, it would just be useful to know what issues >> later builds experienced. >> >> Thanks for the input though. >> >> Sean >> >> >> >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: CentOS Death in 2021
But that does not seem to correlate to the way it is for MacOS or Win. Are you saying they compile from all of those versions of MacOS and Win they reference to supporting. This is a very odd use of semantics. When reading about LiveCode support, to me it doesn’t matter if it is LC Ltd or the LC app. The two are pretty much interchangeable. Both the software and the company Support xyz platform version. It’s not like LC make many/any other products. Especially as the release notes are written SPECIFICALLY for LC the product, not in reference to the company. I cannot see where this inference is coming from. Basically put, if they can’t build it in, for example, Ubuntu 20, then it is not supported fully because of some minor/major issue. So, going back to my question of: what issues have led to support not being passed for them that has led to release notes purposefully omitting mention of these later versions of Linux disro’s? Sean Cole Pi Digital ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: CentOS Death in 2021
On 12/15/20 3:48 AM, Richmond via use-livecode wrote: 2. Stir up trouble. Personally I think that LiveCode central are being a bit @#$%^&* claiming that LiveCode is cross-platform and not saying they support more recent versions than Ubuntu 16.04 and so on. And stirring up trouble means that I think they deserve a collective kick in the source-code for that. I may be in the minority on my opinion on this, and judging from the feedback I expect from this post that may be an understatement, but... I think the team is correct in this. Support means more than "we think this works". Since they currently build and test each released version on an older linux distro, they can't really claim to "support" later versions, even though we can empirically verify that there is essentially no difference when running LC on other/later linuxes. Claiming support would mean dedicating resources to changing the build process, verifying that the resulting build performed to spec on whatever linux version, and also on an ongoing basis dedicating support team resources to whatever issues may arise on the newly officially supported platforms. And at present there's very little ROI for making these changes. Even the modifications that a few of us do contribute require redirecting company resources to verify (or not) before merging into the corpus of releasable code, and with the current worldwide situation I doubt there's a lot of free time to squeeze into redirection from actual revenue-producing streams. Since Ubuntu's EOL date is coming up in the next few months, I expect that the build platform may change soon. But since I can compile from source here on linux mint 20 (Ubuntu based) (as long as I modify the gyp file as in my PR) I don't expect major hiccups nor any major expense in team resources from this migration. 3. As far as I can see (probably not very far), there is no difference in functionality between Xubuntu 16.04 and 20.10; See above, but yes, I agree. -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: CentOS Death in 2021
Hi Sean & Richmond, I think it is best to only support LTS versions and just one desktop (Gnome). This will standardize the platform a bit (Hey, I don't want to start a flame, I'm just saying that Gnome and Ubuntu / Debian are the most used). The problem with LINUX is the sheer number of different desktops and configurations out there. A small company like Livecode cannot be pretended to support all of these variations. I believe that if Debian LTS is supported, Ubuntu will automatically be supported. Ubuntu is a derivative of Debian, so theoretically they should be compatible. With the death of CENTOS there will be a massive migration of people to other distros (like us) and I think Debian and Ubuntu will be the winners. However, it is true that many certified hardware and many government platforms only support RedHat / CENTOS. Especially those in which you have to comply with certifications and bureaucratic regulations. So escaping from IBM is not an option for a big-medium size business. I only code in Livecode with Linux. Honestly, one of the reasons that led me to choose Livecode over other solutions was its Linux support. Best, Hery On 12/14/20 8:19 PM, Sean Cole (Pi) via use-livecode wrote: Hi Richmond, You're probably right. However, with security issues constantly needing keeping up to date with, it's probably worth working out if it is worth supporting Linux at all, then. If they, LC, feel it 'is' worth supporting Linux, it is surely, then, essential to keep up with these latest versions to help their customers avoid security issues. That, I guess, is an issue in of itself. It is remarkable LC is as well supporting of newish OS's as it is, particularly MacOS and Win10, keeping security by encryption and TLS, etc, up to date. Linux is a wayward child, however. Difficult to keep on top off. Even though their update cycles are not as frequent as Win/Mac. Thanks Sean Cole *Pi Digital * On Mon, 14 Dec 2020 at 08:14, Richmond via use-livecode < use-livecode@lists.runrev.com> wrote: "I wonder why LC don’t state support for later Ubuntu, Fedora or Debian builds?" I suspect that LiveCode believes that the uptake of the Linux version is insufficient to justify the effort of testing LC on those platforms. Richmond. On 14.12.20 2:20, Pi Digital via use-livecode wrote: Thanks all. These insights are useful. Hery’s explanation of their choice to move to Debian provides a good argument. I had just tried Ubuntu 20.04 in a parallels virtual machine and my server app worked ok. I will try a Debian build too. I wonder why LC don’t state support for later Ubuntu, Fedora or Debian builds? Sean Cole Pi Digital On 13 Dec 2020, at 19:27, Heriberto Torrado via use-livecode < use-livecode@lists.runrev.com> wrote: Hi Sean, I've been using LiveCode on Ubuntu 16.04 and 18.04 for years (Servers and Desktops) and it worked fine. A years ago we migrated everything to CentOS / RedHat and Fedora (development machines and servers). However, we are going to migrate everything to Debian. Debian is very stable and offers the same user experience on Laptops, Workstations and Servers. Ubuntu is a good system, but after the drift from CentOS with IBM I don't want to put the heart of our systems in the hands of any big company. What would happen if tomorrow Ubuntu is acquired by Microsoft and they decide to charge money for it? That's not the case with Debian: Debian is completely independent and rock solid. I live between Madrid and New York and in both cities there are good professional companies who offer commercial technical support for Debian, so you don't need any big and greedy corps getting their hands on your IT systems. Best, Hery On 12/13/20 12:40 PM, Sean Cole (Pi) via use-livecode wrote: Hi all, I just heard the news that RedHat is going to be dropping support for CentOS. With my recent issues with PDF Printing in CentOS, I was already looking to perhaps try out CentOS8 or another Dist. but now we have this news I'm thinking of going to Ubuntu. The release notes for LC says it supports Ubuntu 16.04, which is cool. But I notice my server host says they have 16.04, 18.04, 20.04 and 20.10. Is anyone out there running LC on one of these later builds of Ubuntu? I'd like to hear your thoughts. Or maybe I should be looking at Fedora. All the very best Sean Cole *Pi Digital * ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list
Re: CentOS Death in 2021
Sean Cole wrote: > On 15 Dec 2020, at 02:52, Richard Gaskin wrote: > >> As Mark Weider noted, the "official" support is merely a reflection >> of their build system, and it relies on a version of Ubuntu still >> actively getting security updates. > > That doesn’t seem to be stated or inferred in the release notes. Correct, which is why I cited Mark Weider. He and I have each had conversations with the core team on this, and what he wrote is correct. It seems this confusion arises from the ambiguity introduced by having "LiveCode" mean multiple different things: it's the product, it's the language the product runs on, and it's the company. I just submitted a docs request on this, suggesting that in the Release Notes they change: "LiveCode supports the following Linux distributions..." ...to: "LiveCode Ltd supports the following Linux distributions..." ...so it becomes clearer that the limitation is only with regard to the company's commitment to provide technical support, and not a contradiction of the clarification they provide later in the Notes about the full scope of expected compatibility: https://quality.livecode.com/show_bug.cgi?id=23035 -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: CentOS Death in 2021
I would pick a small fight here. On 15.12.20 11:24, merakosp via use-livecode wrote: Hello Sean, Off the top of my head, the main Linux issues that are currently unresolved are: 1. The player object is broken on all Linux distros. You might be able to workaround this by using shell commands with mplayer. I have a feeling that the player object is not broken as it NEVER worked properly on Linux in the first place. 2. The browser widget is broken in most Linux distros. It might work for just displaying a webpage, but not for typing into input fields of the webpage. I am not sure if there is a workaround for this. 3. Also, you might experience window layering problems with some Linux window manager (e.g. Cinnamon). Hope this helps, Panos -- On Tue, 15 Dec 2020 at 10:42, Pi Digital via use-livecode < use-livecode@lists.runrev.com> wrote: On 15 Dec 2020, at 02:52, Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: As Mark Weider noted, the "official" support is merely a reflection of their build system, and it relies on a version of Ubuntu still actively getting security updates. That doesn’t seem to be stated or inferred in the release notes. It’s under the heading ‘Platform Support’ which infers, like ‘System Requirements’ might, “This is what it will run on”. Indeed, under the heading it states: The engine supports a variety of operating systems and versions. This section describes the platforms that we ensure the engine runs on without issue (although in some cases with reduced functionality). Then under Linux it states: LiveCode supports the following Linux distributions, on 32-bit or 64-bit Intel/AMD or compatible processors: Ubuntu 14.04 and 16.04 Fedora 23 & 24 Debian 7 (Wheezy) and 8 (Jessie) [server] CentOS 7 [server] Then lists the Core and ‘optional’ GUI feature requirements. None of this states or infers that >=Ubuntu 18, >=Fedora 25, >=Debian 9 or >=CentOS 8. So we are left assuming that these unlisted platforms/versions, much like macOS 10.16, is “Unsupported”! Hence my initial question/request for community knowledge/experience. I’m not seeking to stir up trouble (for a change). I’m seeking understanding and wisdom. If LC is Not Supported on later builds, what aspects do not function in your (plural, ie, everyones) experiences. Because LC write “This section describes the platforms that we ensure the engine runs on without issue”, it would just be useful to know what issues later builds experienced. Thanks for the input though. Sean ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: CentOS Death in 2021
1. I have never, ever experienced any problems at all with any versions of LiveCode on any versions of Xubuntu that are more 'modern' than 16.04. 2. Stir up trouble. Personally I think that LiveCode central are being a bit @#$%^&* claiming that LiveCode is cross-platform and not saying they support more recent versions than Ubuntu 16.04 and so on. And stirring up trouble means that I think they deserve a collective kick in the source-code for that. 3. As far as I can see (probably not very far), there is no difference in functionality between Xubuntu 16.04 and 20.10; admittedly though I stopped using 16.04 about April 2017, so I may have forgotten something. Richmond. On 15.12.20 10:40, Pi Digital via use-livecode wrote: Hence my initial question/request for community knowledge/experience. I’m not seeking to stir up trouble (for a change). I’m seeking understanding and wisdom. If LC is Not Supported on later builds, what aspects do not function in your (plural, ie, everyones) experiences. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: CentOS Death in 2021
Hello Sean, Off the top of my head, the main Linux issues that are currently unresolved are: 1. The player object is broken on all Linux distros. You might be able to workaround this by using shell commands with mplayer. 2. The browser widget is broken in most Linux distros. It might work for just displaying a webpage, but not for typing into input fields of the webpage. I am not sure if there is a workaround for this. 3. Also, you might experience window layering problems with some Linux window manager (e.g. Cinnamon). Hope this helps, Panos -- On Tue, 15 Dec 2020 at 10:42, Pi Digital via use-livecode < use-livecode@lists.runrev.com> wrote: > > > On 15 Dec 2020, at 02:52, Richard Gaskin via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > As Mark Weider noted, the "official" support is merely a reflection of > their build system, and it relies on a version of Ubuntu still actively > getting security updates. > > That doesn’t seem to be stated or inferred in the release notes. It’s > under the heading ‘Platform Support’ which infers, like ‘System > Requirements’ might, “This is what it will run on”. Indeed, under the > heading it states: > > >> The engine supports a variety of operating systems and versions. This > section describes the platforms that we ensure the engine runs on without > issue (although in some cases with reduced functionality). > > > Then under Linux it states: > > >> LiveCode supports the following Linux distributions, on 32-bit or > 64-bit Intel/AMD or compatible processors: > >> Ubuntu 14.04 and 16.04 > >> Fedora 23 & 24 > >> Debian 7 (Wheezy) and 8 (Jessie) [server] CentOS 7 [server] > > > Then lists the Core and ‘optional’ GUI feature requirements. None of this > states or infers that >=Ubuntu 18, >=Fedora 25, >=Debian 9 or >=CentOS 8. > > So we are left assuming that these unlisted platforms/versions, much like > macOS 10.16, is “Unsupported”! Hence my initial question/request for > community knowledge/experience. I’m not seeking to stir up trouble (for a > change). I’m seeking understanding and wisdom. If LC is Not Supported on > later builds, what aspects do not function in your (plural, ie, everyones) > experiences. > > Because LC write “This section describes the platforms that we ensure the > engine runs on without issue”, it would just be useful to know what issues > later builds experienced. > > Thanks for the input though. > > Sean > > > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: CentOS Death in 2021
> On 15 Dec 2020, at 02:52, Richard Gaskin via use-livecode > wrote: > > As Mark Weider noted, the "official" support is merely a reflection of their > build system, and it relies on a version of Ubuntu still actively getting > security updates. That doesn’t seem to be stated or inferred in the release notes. It’s under the heading ‘Platform Support’ which infers, like ‘System Requirements’ might, “This is what it will run on”. Indeed, under the heading it states: >> The engine supports a variety of operating systems and versions. This >> section describes the platforms that we ensure the engine runs on without >> issue (although in some cases with reduced functionality). Then under Linux it states: >> LiveCode supports the following Linux distributions, on 32-bit or 64-bit >> Intel/AMD or compatible processors: >> Ubuntu 14.04 and 16.04 >> Fedora 23 & 24 >> Debian 7 (Wheezy) and 8 (Jessie) [server] CentOS 7 [server] Then lists the Core and ‘optional’ GUI feature requirements. None of this states or infers that >=Ubuntu 18, >=Fedora 25, >=Debian 9 or >=CentOS 8. So we are left assuming that these unlisted platforms/versions, much like macOS 10.16, is “Unsupported”! Hence my initial question/request for community knowledge/experience. I’m not seeking to stir up trouble (for a change). I’m seeking understanding and wisdom. If LC is Not Supported on later builds, what aspects do not function in your (plural, ie, everyones) experiences. Because LC write “This section describes the platforms that we ensure the engine runs on without issue”, it would just be useful to know what issues later builds experienced. Thanks for the input though. Sean ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
