LiveCode Forums.

X wrote:

FourthWorld wrote: It's helpful to know this a non-issue for you.

Sometimes I feel like that "last samurai", fighting for and standing by RR/LC Empire which unfortunately is losing ground on the Linux landscape

Linux has remained at 1-3% (depending on whose stats you read) for many years. I enjoy it and would like to see that grow, but for the reasons I outlined in this post on the Ubuntu forum I just don't see much growth potential for Linux until OEMs stop ripping off their shareholders by refusing to differentiate:
http://ubuntuforums.org/showthread.php? ... st11618651

While Linux has remained a slender minority on the desktop (yes, even 30+ million is still a minority), RunRev continues to deliver enhancements to their Linux engine with each release. In fact, RunRev's investment in Linux is greatly disproportionate to revenues derived from it. Yet they do it because they like it and it reflects well on their omni-platform mission, and those of us who like Linux really like it so we're the squeaky wheels that get the grease, much as RunRev devotes far more than 10% of their development time to their Mac engine, even as the Mac audience has never exceeded 10% of total computer users.

And like the Mac and Windows engines, the Linux engine is not entirely bug-free. Indeed, none of those OSes are themselves bug-free.

And as you noted earlier Linux is a complex beast with multiple layers which can make tracking down problems from specific interactions of components, like this memory leak, unusually challenging compared to the level of effort required to fix such a problem on more heterogeneous OSes.

That said, I suspect RunRev will look into this soon (report #10141 was submitted only two days ago), and if it can be confirmed there I'd be surprised if we don't see a fix in the next release. Memory leaks can be very hard to track down, but usually not that hard to fix once the root cause is known.

Of course that assumes the bug is in LiveCode. So far the evidence available leaves that as an open question, esp. given the very few leaks that have ever cropped up in the LC engine to date vs. the many well-documented leaks in Xorg. It may be LC, but it may not. It'll take more thorough investigation to know for sure.

That is just the thing though. If companies are going to sell Linux software, and charge the same rates as Windows and Mac versions, then they should apply the same amount of effort as other platforms. Rather than telling clients that Linux is just not a wide enough user-base to justify the work, why not instead charge a lower rate, or provide free upgrades, or give additional support in an effort to expand the user-base? Or, just stop selling Linux software instead?

It can be a little frustrating to pay and then be told that your version is not supported, or is too difficult to test properly. Well, linux users traditionally like to help out with testing, support and bug reporting, and even more so when a company propagates that sort of community.
I am not feeling a strong Linux community here. It seems more of a dwindling amount of interest on client and company sides, which is a shame since there is much potential there, especially if Ubuntu's app-store were used for marketing more to the Linux base. There already is one developer application available that LiveCode would run circles around..

ghettocottage wrote:If companies are going to sell Linux software, and charge the same rates as Windows and Mac versions, then they should apply the same amount of effort as other platforms. Rather than telling clients that Linux is just not a wide enough user-base to justify the work, why not instead charge a lower rate, or provide free upgrades, or give additional support in an effort to expand the user-base? Or, just stop selling Linux software instead?

Well, that's an option, but I hope they don't pursue that.

I should note that I don't work for RunRev, so anything I say is just my own opinion. Like you, I'd like to see even more work on the Linux engine, but I'm also able to do pretty much anything I need to switching my work between Mac and Ubuntu all day, so I haven't felt much lacking there. Down the road I may use RevBrowser and would like to see a Linux version of that, and with any luck they'll have that in place before I need it.

With the memory issue which prompted this thread, I haven't seen it myself so I've had generally good experiences with RunRev's Linux engine, and FWIW I've found RunRev to be responsive to bug reports submitted with a reproducible recipe. There are outstanding bugs for all supported platforms, not just Linux, as there are with the OS vendors for the OSes themselves.

Have you seen this memory issue on your system? If so, it may be helpful to add your system config to the RQCC report, or submit it to support@runrev.com with the RCQQ report number so a rep there can post it for you.

It can be a little frustrating to pay and then be told that your version is not supported, or is too difficult to test properly.

Which RunRev staffer told you that? Like every other platform they're selling LiveCode for, the Linux engine is supported.

Well, linux users traditionally like to help out with testing, support and bug reporting, and even more so when a company propagates that sort of community.

An excellent point, which is why I find so many of the RQCC reports puzzlingly vague and lacking important details.

While I don't work for RunRev, I have worked as a contractor for them many years ago, and stay in touch with them from time to time. I've been advocating ways we can make better use of the can-do spirit in the Linux community to help improve the product experience. Hopefully we'll see some of that become evident in the not-too-distant future.

I am not feeling a strong Linux community here.

Heck, I'm not feeling a strong Linux community anywhere on the planet outside of the Linux conferences and user groups I attend.

OEMs largely refuse to ship with anything but Windows, and it would never occur to most "normal" people to replace the OS that came with their computer with something they downloaded off the Internet. Whether we like it or not, those of us who choose Linux are a rare breed.

Add to that the pundits proclaiming the so-called "post-PC era" (in which, ironically, 75% of sales of computing devices remain PCs - see http://www.zdnet.co.uk/blogs/jacks-blog ... -10025689/ ), and the gold rush mentality of the gonna-be-the-next-Angry-Birds mobile craze, and it's not surprising that like so many other companies RunRev is devoting a lot of its engineering resources to the other Linux, Android.

I dig Linux, but with a 3%-and-not-growing desktop share I have no illusions about its importance in the consumer world at large, at least until OEMs wake up and smell the differentiation.

In the meantime, RunRev continues to put disproportionate resources into the Linux engine, and it gets better with each build.

Even in this thread, a majority of respondents are either minimally or completely unaffected by the seeming memory leak, and it hasn't yet been determined that this isn't just another Xorg issue.

While I share your enthusiasm for mo' Linux love, I don't think the current situation is all that bad.


Now here's a challenge to the can-do Linux community:

Ubuntu has the Software Center, but to get apps there they need to be delivered to a PPA as .deb packages.

Who has the time and interest to make a drag-and-drop tool to turn a folder containing the standalone, the .desktop file, the icon, and any other parts into a valid .deb package?

If we can demonstrate our belief in the value of the Ubuntu market with such a tool, it'll be very useful to others as well, and all of us will be better off.

I've been wanting to build such a thing for some time, but my client projects have expanded in scope so it's been moved to a very back burner. If anyone here wants to take this up I'd be happy to help however I can.

Hmm. Sounds like a pretty cool little project actually. Do you already have a script that does that?

ghettocottage wrote:Hmm. Sounds like a pretty cool little project actually. Do you already have a script that does that?

I have nothing written yet. I started to look into the command-line tools for making .deb packages, but then the client work started to build so I had to set it aside. I think it should be most cost-effective to use LC to simply build the GUI for the shell calls.

Very glad this interests you. We might be able to enlist Andre Garzia to help as well (but probably not Mark Wieder, since he's a Fedora snob <g>).

Ack! Marginalized again!

Yes, we use Red Hat and Fedora at work. I haven't looked at Ubuntu since version 8 or so. I'd probably take another look if it weren't for those silly GUI front ends.

mwieder wrote:Yes, we use Red Hat and Fedora at work. I haven't looked at Ubuntu since version 8 or so. I'd probably take another look if it weren't for those silly GUI front ends.

You can use Gnome Shell with Ubuntu if that helps; it can be downloaded from the Ubuntu Software Center and selected at login.

But that may not be necessary: does Fedora provide support for .deb packages?

I started a new thread for discussing this:
http://forums.runrev.com/phpBB2/viewtop ... 20&t=11641

I can confirm this. On my system with Kubuntu 11.10 64bit I'm experiencing huge Memory Leak when resizing/manipulating graphic objects on LC 5.5. LC4.5 works fine.
Xorg RAM usage went from 1.3% up to 31.9% in less than a minute, that is about 2.5GB of RAM!

Test System:
CPU: Intel i5
RAM: 8GB DDR3
Graphic Card: NVidia 560GTX
OS: Kubuntu 11.10 64Bit
Graphic Driver: 173 (from Ubuntu Repository)

Thanks for the additional info, Dimaxter.

In this user-to-user forum there's little chance that info can make a difference here, but if you could submit to the bug report opened for this three days ago it would be helpful:
http://quality.runrev.com/show_bug.cgi?id=10141

If you don't have access to the RQCC you can submit that info with the RQCC report number to support@runrev.com and they'll include it for you.

Thanks again for your help on this.

Dimaxter-

I notice you're running on a 64-bit OS. I wonder if that makes a difference.

For those of you who are not in the Developer program and don't have access to the Rev Quality Control Center, issue #10141, first submitted March 30, just had this note added by Michael McCreary of the RunRev team:

Thanks very much for the report. We've tried this on various systems and
appear to have finally tracked it down. We've put a fix in which will be
available in the next build.

Warm Regards

Michael

Many thanks to X for submitting this report, and to the others who helped provide additional details which were useful in tracking down the root cause.

YAY!

I think with the rev team able to devote so few resources to the linux product, it's really up to us to try to narrow down problems as much as we can to give the team something to work with. This thread is a fine example, pinpointing the problem to a probable driver issue so that they can replicate and fix it.

Kudos to Michael and the rev team and to the folks who persisted here.

mwieder wrote:YAY!

I think with the rev team able to devote so few resources to the linux product, it's really up to us to try to narrow down problems as much as we can to give the team something to work with. This thread is a fine example, pinpointing the problem to a probable driver issue so that they can replicate and fix it.

Kudos to Michael and the rev team and to the folks who persisted here.

Well said. I'm especially grateful for ghettocottage's can-do spirit, and I agree that as long as Linux has such a slender market share there's a lot we can do to help engine fixes and enhancements along, exactly as you describe.

On the 8th this issue was officially marked as "Fixed for 5.5.1-dp2":
http://quality.runrev.com/show_bug.cgi?id=10141

Interestingly, the release notes for that version describe the issue as:
"Memory leak when shared memory off on Linux"

That's an important detail which explains why some configurations didn't show the issue.

Thanks again to all who contributed info for this one.

Please keep 'em coming - Linux is an increasingly important platform, so we'll want to make sure the LiveCode engine for it is running as smoothly as possible.