Hiya, I totally agree.
Looking at the huge mass of applications available for Linux (professional and hobby) it doesn't tally that it's a 'Linux' issue: Simple as that.
Comparing notes with developers on the ease of programming disparate Operating Systems, Linux comes out on top as the 'easiest' overall (aside from developer tools) principally due to it's open nature.
I could mention the office suite from a large OS vendor that doesn't behave as it should (they wrote the OS, they should know better!). Or I could mention the BSoD every time a Blackberry was UNPLUGGED from the system due to a hotfix, so you had to go to a previous restore point and install the hotfix for the hotfix. Who carried the blame? The Blackberry vendor or the OS vendor? You can really go many routes on this one.
What's it to do with Linux in this instance? Even beginners get to grips with programming in Linux without causing what is currently been griped at with Rev on Linux.
If you can't see that then you need to use Linux more to fully understand the point. Linux users aren't 'ranting', they just can't see why the rest can't see how simple the issue is.
Rev on Linux: At this time, it just ain't right. Cheers, Luis. On 16/07/2010 09:24, Peter Alcibiades wrote:
"There is no "Linux" per se. Linux is like blocks, modules that people snap together at will. Without a known set of variables, Rev is very likely to fail in some areas depending on which software the current user has installed. " Jacque, I don't think this is either true, or a useful explanation of why, for instance, the editor crashes in my plain minimalist install of Debian on cut and paste. If it were true, then lots of applications that do cut and paste, which is just about all of them, would crash. The fact is, they do not. If it were true, then it would be almost impossible for virtual desktops to work on all applications, but they do work. Not by the way any sort of exotic way of working, commonplace for the mainstream Linux user. Commonplace in fact for ordinary users, once you have showed them a few times how to use virtual desktops. The way to look at this thing is to figure out what Rev is doing differently from other apps. What exactly is Rev doing with its editor, which is not a terribly complicated sort of functionality, which makes this editor, unlike any other, slowdown and freeze? How exactly has Rev implemented the IDE so that you can't put the property inspector on one desktop and the editor on another? How is Rev relating to the system print functionality that makes revPrintField not work? Where is it getting its font lists from? Its not the same place as every other app gets them. Rev's problem is not that it is being installed with deep system functionality into a complex multifarious environment, and some of this deep functionality is understandably failing to work. Rev's problem is that in very simple functions, not deep at all, it is not relating to identical and unchanging features of the OS functionality in the same way that all the other apps do. As an analogy, it would be like writing your app so its installer failed to put a starter icon on the desktop in Windows, and then saying, Oh Well, the problem is no app store, people just install whatever they want on Windows, so its an unpredictable environment. Yes, it is, but that is not the problem, the problem is how you wrote your installer to do something very simple and access very basic functionality. We need to stop making excuses! Peter
_______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
