Page 18 of 32 FirstFirst ... 8161718192028 ... LastLast
Results 171 to 180 of 315

Thread: Why Mono Is Desirable For Linux

  1. #171
    Join Date
    Oct 2011
    Posts
    226

    Default

    Quote Originally Posted by ciplogic View Post
    It logically follows that Mono is the one language/platforms, isn't it? If not, you should put at least in a separate paragraph, isn't so?
    If your behind logic is that you're screwed if the one platform goes away, I can say to you at least 4 projects having various levels of supporting the CLR virtual machine (all are here):
    - Microsoft
    - Mono
    - DotGNU
    - VMKit, a project of LLVM
    So, in case a nuclear bomb hit Redmond (never hope it happens) and because of that they attack with patents and kill Xamarin as a bussiness, there will be two half-baked implementations of CLR/.Net
    In balance, let's take Qt, how many vendors support it?
    - it was Nokia
    - it is Digia now
    What if Digia discontinue Qt, how many alternative Qt implementations do you have?
    Based on raw numbers, I will pick Mono and .Net over Qt, seems much more safer, isn't so?
    No.

    But don't only develop on Mono. It is never good to rely on one language/framework.
    Look at the bold. I said not ONLY Mono. Meaning you should know other things. If the word Only was not there, you would be right.
    I said one language/framework, that does not refer to mono. If I said a instead of one you would have a point. Even if I said a that doesn't really refer to mono, but then the sentence would refer to all languages/framework.
    But perhaps, I should have been more clear.

    Now the other points.

    If a nuke hit redmond and every MS office, machines running .NET would be safe, just as machines running windows. It won't magically stop working. However it has no future. It doesn't matter that there are open source implementations. Other then MS, mono is the only practical one and there the issue arises:
    The work of hundreds of paid employees will not be at Xamarin. Many parts of MS .NET will never be included in Mono since they don't make sense and the developers have no intention of porting it.
    Mono would keep .NET alive if MS vanished, it would be much, much worse if .NET vanished and mono did not exist either. But it still is not better then Qt in this scenario.

    Why Qt has a very solid future:
    First Digia is not the only vendor. There are companies build around Qt like ICS, and KDAB. There are vendors besides Digia.

    Digia will never kill off Qt. It's a really huge product for them. Digia would have to go bankrupt, or sell of Qt. They won't discontinue. So many bigs companies are invested in and use Qt. There are legal obligations Digia must fulfill.

    Qt is open source while .NET isn't. Mono must reverse engineer Microsoft's .NET, the official implementation. While Qt's official implementation is open source and high documented.

    Why would Qt have an alternative implementation? Qt isn't a language. It's like reimplementing a library. No damn point.

    Another reason Qt has a good future: KDE.

    KDE has a legal agreement that Qt must remain open source and that there must be a major release at least once a year, or else KDE gains access to a BSD licensed version of Qt.

    Qt is open source, has other vendors, well documented, is TRULY cross platform, and has many multinational billion dollar companies invested in it.
    Qt has more platforms (except in mobile, they are only now adding iOS and android support).
    Qt works on Windows, Mac, Linux, BSD (unofficial?), QNX, VxWorks, embedded linux, and Windows CE. I think it works on some Unix flavors too.

    In relaity, both Qt and .NET have a very solid future ahead.
    Last edited by n3wu53r; 09-17-2012 at 10:22 PM.

  2. #172
    Join Date
    May 2012
    Posts
    350

    Default

    Quote Originally Posted by jrch2k8 View Post
    miss multiplataform capabilities[sparc ARM power systems]
    Wait, what?

    http://ftp.de.debian.org/debian/pool....1-6_armel.deb
    http://ftp.de.debian.org/debian/pool....1-6_sparc.deb

  3. #173
    Join Date
    Oct 2008
    Posts
    901

    Default

    Just because a program is packaged by Debian doesn't mean it works properly.

  4. #174
    Join Date
    May 2012
    Posts
    350

    Default

    Quote Originally Posted by yogi_berra View Post
    Just because a program is packaged by Debian doesn't mean it works properly.
    Code:
    (sid)directhex@smetana:~$ mono --version
    Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-6)
    Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
    	TLS:           __thread
    	SIGSEGV:       normal
    	Notifications: epoll
    	Architecture:  sparc
    	Disabled:      none
    	Misc:          
    	GC:            Included Boehm (with typed GC and Parallel Mark)

    Code:
    directhex@abel:~/mono-2.10.8.1$ mono/mini/mono --version
    Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-3)
    Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
    	TLS:           __thread
    	SIGSEGV:       normal
    	Notifications: epoll
    	Architecture:  armel,soft-float
    	Disabled:      none
    	Misc:          softdebug 
    	LLVM:          supported, not enabled.
    	GC:            Included Boehm (with typed GC and Parallel Mark)
    Wait, what? Can you show me the bugs relating to these architectures on http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mono ?

  5. #175
    Join Date
    Jun 2010
    Posts
    219

    Default

    Quote Originally Posted by ciplogic View Post
    I don't see any other target where Qt keeps you safe(r) to sleep than Mono and his support as .Net. And eventually DotGNU and VMKit will still give a chance to use your code even if both Microsoft and Xamarin would disappear (if it would be still some interest in C# in 20 years from now)
    Enough claims. Facts:
    • C++ / Qt work, NOW, on all platforms
    • C# / Mono does not fully work, has caveats and bugs
    • C++ / Qt are both very mature technologies and are proven for general purpose application development
    • C# / Mono is not
    • C++ / Qt are very resource friendly
    • C# / Mono is not
    • C++ has had massive mindshare and support for well over 20 years now
    • C# doesn't have even close to the level of support C++ does, to this day.


    Therefore:
    There is no legitimate reason, ever, to choose Mono/C# over C++ and Qt. As another poster said, it is just laziness and incompetence.

  6. #176
    Join Date
    May 2012
    Posts
    350

    Default

    Quote Originally Posted by kazetsukai View Post
    Enough claims. Facts:
    • C++ / Qt work, NOW, on all platforms
    • C# / Mono does not fully work, has caveats and bugs
    Qt has better support across Linux architectures than Mono, e.g. support for HP-PA.

    C# and Mono are better supported on mobile - Mono for Android, MonoTouch, and WP7 cover more than 90% of the US smartphone OS market. Comparatively, Qt is in "experimental pre-alpha" stage for iOS and Android and not an option for WP7. Symbian & Blackberry support in Qt accounts for less than 7% of the US smartphone OS market.

    Support for Windows and Mac is comparable across both. Support for Linux on major architectures is equivalent across both.
    • C++ / Qt are both very mature technologies and are proven for general purpose application development
    • C# / Mono is not
    Qt is about twice the age of Mono - 1992 versus 2002. In most circles, the word "mature" could be used here.

    As for proven, again, mobile has pointed towards Mono rather than Qt. It's a more flexible choice for embedding scenarios, e.g. gluing into game engines. On the desktop Qt is far more popular, due in no small part to KDE and to the mature tools for Windows use. EA are an example of a Qt user, for their Origin client on Windows. EA are also an example of a Mono user, for The Sims 3 on Windows, Mac, 360 and PS3.
    • C++ / Qt are very resource friendly
    • C# / Mono is not
    There's really very little in it between Qt and Mono for most resources. Qt may be faster for CPU usage, but that's not really something one encounters in user-interactive applications.
    • C++ has had massive mindshare and support for well over 20 years now
    • C# doesn't have even close to the level of support C++ does, to this day.
    They're useful for different scenarios. Mono doesn't replace C++. And interop between the two is of major importance to users.

    As for the Linux desktop, VERY ANGRY NERDS TYPING IN BOLD AND CAPS have been very effective at scaring users away from Mono, and keeping developers on Windows.

    Therefore:
    There is no legitimate reason, ever, to choose Mono/C# over C++ and Qt. As another poster said, it is just laziness and incompetence.
    There are lots of legitimate reasons to choose Mono/C# over C++ and Qt. But because they're not the uses you care about, you project into all cases and say and say "never". This is silly. There are times Qt with C++ is the right choice, times with Mono with C# is the right choice, and times when some combination thereof is the right choice.

  7. #177
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    399

    Default

    Quote Originally Posted by kazetsukai View Post
    Enough claims. Facts:
    • C++ / Qt work, NOW, on all platforms
    • C# / Mono does not fully work, has caveats and bugs
    • C++ / Qt are both very mature technologies and are proven for general purpose application development
    • C# / Mono is not
    • C++ / Qt are very resource friendly
    • C# / Mono is not
    • C++ has had massive mindshare and support for well over 20 years now
    • C# doesn't have even close to the level of support C++ does, to this day.


    Therefore:
    There is no legitimate reason, ever, to choose Mono/C# over C++ and Qt. As another poster said, it is just laziness and incompetence.
    [*]C++ / Qt work, NOW, on all platforms
    Excluding Android, iOS, Windows Phone 7 (and 8)
    Does it have bugs?
    https://bugreports.qt-project.org/se...avigator.jspa?
    I just filtered bugs that are: priority greater than normal, open, and Qt
    On the head of the list I have:
    " Displaying issues 1 to 50 of 1235 matching issues. "

    [*]C# / Mono does not fully work, has caveats and bugs
    The Mono's equivalent is: " 126 bugs found.", this is without filtering by priority (based on Xamarin's Mono Runtime bug tracker)

    [*]C++ / Qt are both very mature technologies and are proven for general purpose application development[*]C# / Mono is not
    If you take CLang as a very mature C++ technology, may you elaborate? Mono's C# compiler is at least 5 years older by any measure. QML is proven and C#/Linq is not?
    Proven technologies that I know that they work in Mono (and .Net) that have no equivalent in C++/Qt:
    - faster than signal/slot performance, by at least an order or magnitude
    - no need to automatically reference counting, and using reference memory does not require a hit in performance
    - garbage collector (you can do it with JavaScript in QML, but not properly in Qt itself)
    - I'm not aware a dynamic language programming capabilities in C++/QT (without JavaScript in Qml)
    - no Linq, Tulip is much more limited
    - string manipulation class QString is a mess, at least compared with C#'s string

    [*]C++ / Qt are very resource friendly[*]C# / Mono is not

    Events driven code (with signals/slots) is faster in C#. If you dream that Qt is so lean, try search these words in Google box: "Amarok mem" and the proposal is "Amarok memory hog". If you try the same experiment with "Monodevelop memory" it will suggest: "MonoDevelop memory profiler", for Banshee: "banshee memory leak" (which is a much better wording that most people will define for their software). Do you have any hard numbers to point to? Or is just slander?

    [*]C++ has had massive mindshare and support for well over 20 years now[*]C# doesn't have even close to the level of support C++ does, to this day.

    Eventually a thing I think you are right: TIOBE index states: (source)
    4 3 C++ 9.147% +0.30% A
    5 4 C# 6.596% -0.22% A

    Do you see, 9.2% in usage compared with 6.5 % usage.
    Don't forget anyway that you can use C (19.2%) , Java (16.5%) or Objective C (9.7%), all three are more popular as both. ObjectiveC is similar as age with C++ (yet a bit younger), C is certainly older, and is crucial to write in kernel or in GCC codebase, and of course with Gtk, and ObjectiveC is critical for iOS development.
    And if you decide to use C, for not critical performance code, if you need to write fast an UI, I recommend to you to use C#/Gtk#.
    Last edited by ciplogic; 09-18-2012 at 12:52 PM.

  8. #178
    Join Date
    Jun 2009
    Posts
    1,189

    Default

    LLVM Jit infrastructure only is supported in and quoting "A Just-In-Time (JIT) code generation system, which currently supports X86, X86-64, PowerPC and PowerPC-64." which should slows down mono runtime enough to consider Java or python for example.

    additionally LLVM seems to be able to run on sparc/mips but not as a first class citizen[make sense since sparc is very oracle this days], googling seem llvm is a major headache to compile in some of this plataforms, especially in solaris/niagara2 combo.

    note that when i say not supported doesn't mean don't work, it just means can't do anything serious until later point in time or toy for have fun but no to work.

  9. #179
    Join Date
    May 2012
    Posts
    350

    Default

    Quote Originally Posted by jrch2k8 View Post
    LLVM Jit infrastructure only is supported in and quoting "A Just-In-Time (JIT) code generation system, which currently supports X86, X86-64, PowerPC and PowerPC-64." which should slows down mono runtime enough to consider Java or python for example.
    Er, no. Mono's standard JITter and GC are still a hundred time faster than Python. Mono's LLVM support is still very early days, and is certainly not shipped in any distributions that I'm aware of.

    Default Mono practice is to use the supplied JITter (not LLVM), and the default garbage collector (still Boehm). Mono's runtime has some support for Alpha, AMD64, ARM, HP-PA, Itanium, MIPS, PowerPC, s390, SPARC, and i386. Some of these may be bitrotted (e.g. we don't ship 31-bit s390 builds in Debian, only 64-bit).
    Last edited by directhex; 09-18-2012 at 12:58 PM.

  10. #180
    Join Date
    Jun 2009
    Posts
    1,189

    Default

    Quote Originally Posted by ciplogic View Post
    [*]C++ / Qt work, NOW, on all platforms
    Excluding Android, iOS, Windows Phone 7 (and 8)
    Does it have bugs?
    https://bugreports.qt-project.org/se...avigator.jspa?
    I just filtered bugs that are: priority greater than normal, open, and Qt
    On the head of the list I have:
    " Displaying issues 1 to 50 of 1235 matching issues. "

    [*]C# / Mono does not fully work, has caveats and bugs
    The Mono's equivalent is: " 126 bugs found.", this is without filtering by priority

    [*]C++ / Qt are both very mature technologies and are proven for general purpose application development[*]C# / Mono is not
    If you take CLang as a very mature C++ technology, may you elaborate? Mono's C# compiler is at least 5 years older by any measure. QML is proven and C#/Linq is not?
    Proven technologies that I know that they work in Mono (and .Net) that have no equivalent in C++/Qt:
    - faster than signal/slot performance, by at least an order or magnitude
    - no need to automatically reference counting, and using reference memory does not require a hit in performance
    - garbage collector (you can do it with JavaScript in QML, but not properly in Qt itself)
    - I'm not aware a dynamic language programming capabilities in C++/QT (without JavaScript in Qml)
    - no Linq, Tulip is much more limited
    - string manipulation class QString is a mess, at least compared with C#'s string

    [*]C++ / Qt are very resource friendly[*]C# / Mono is not

    Events driven code (with signals/slots) is faster in C#. If you dream that Qt is so lean, try search these words in Google box: "Amarok mem" and the proposal is "Amarok memory hog". If you try the same experiment with "Monodevelop memory" it will suggest: "MonoDevelop memory profiler", for Banshee: "banshee memory leak" (which is a much better wording that most people will define for their software). Do you have any hard numbers to point to? Or is just slander?

    [*]C++ has had massive mindshare and support for well over 20 years now[*]C# doesn't have even close to the level of support C++ does, to this day.

    Eventually a thing I think you are right: TIOBE index states: (source)
    4 3 C++ 9.147% +0.30% A
    5 4 C# 6.596% -0.22% A

    Do you see, 9.2% in usage compared with 6.5 % usage.
    Don't forget anyway that you can use C (19.2%) , Java (16.5%) or Objective C (9.7%), all three are more popular as both. ObjectiveC is similar as age with C++ (yet a bit younger), C is certainly older, and is crucial to write in kernel or in GCC codebase, and of course with Gtk, and ObjectiveC is critical for iOS development.
    And if you decide to use C, for not critical performance code, if you need to write fast an UI, I recommend to you to use C#/Gtk#.
    1.) well that is true mono "support" more mobile devices but there is a valid reason for it, but for example mono runtime is not in google play store neither is supported for google, ios seem to be in better position but still not supported by apple in any way.i don't mean is bad for small developer studio or independants but for big studios john doe CEO is a big fat no way in hell, like they reject using ngix instead of apache for example.On the other hand qt5 was meant to be the next big mobile thing[meego/symbian combo] but our friend elop killed nokia forcing Digia/community to rethink the strategy and one thing Digia seem to understand properly is that you need to do this in a way that you can get support and acceptance from the vendors, so john doe CEO feels it doing a good investment, and so far they have made nice steps with vxworks[big fat market of industrial RT devices] and QNX[blackberry if survive tho], from the code quality POV Qt support android/ios not that far behind but is not enterprise grade ready yet.

    2.) check bugzilla is uterlly useless and i no way represents the quality of the code and since Qt4 is much widely used and supported is ovbious the list will be bigger, you have reports in there from guys don't like the qt logo up to plasma active automated core dumps from arm systems passing all the way to ppl whining for clang support in freebsd 10 git. ofc both systems [mono/qt] have bugs that is a no brainer.

    3.) don't get why you bring clang but Qt support clang/ICC/gcc/sun studio/portland group/ekopath/AIX compiler and many others depending the OS/cpu arch check the mkspec directory
    4.)signal/slot is not part of any C++ ISO specification and if you used Qt like ever you will know is just a meta object that get translated to bare C++ code at compilation time, would be interesting how you measure performance impact here and as far as i know is irrelevant since you signal/slots can be maybe 1% of you total codebase[unless we are talking about some serious crappy coding]
    5.) "no need to automatically reference counting, and using reference memory does not require a hit in performance" this is basically what a garbage collector do ... and it does hit performance a lot and require lot of memory to do so, you just don't see it cuz the GC run as another process[in some OSes hidden]
    6.) C++ is a compiled low level language and it doesnt require a garbage collector neither is part of the ISO spec but if you know the basics keep memory in check is pretty easy and QML is not a JS VM nor is you firefox/chrome JS rendered. QML get translated to C++ code directly[JS syntax is just used to make thing easier for designers] and use the internal render API of the running OS especially in Qt5 lighthouse aka aero/gdi/cocoa/X11/opengl/openvg/egl/etc
    7.)"- I'm not aware a dynamic language programming capabilities in C++/QT (without JavaScript in Qml)" QtScript and QML and C++[bit harder]
    8.) mmm tulip maybe maybe not depends on what you wanna do, for me works just peachy but maybe you need something i don't use
    9.) well i particularly find QString quite powerful and easy to use, maybe a more specific example?? string manipulation is quite an extensive issue
    10.) this is actually a classic newbie problem with linux, i mean linux try to use as much memory as is possible to cache/preload stuff preemptively and secondly you have process memory and virtual memory which can be confusing, in the case of amarok which is an KDE application need to load in memory all it dependencies[kdelibs/qt/libvisual/gstreamer/etc] so if you use gnome amarok will show a massive memory usage cuz gnome preload his libraries and dependencies[gtk/gfk/bonobo/atk/etc] not the ones from kde but if you use KDE you will see amarok actually is quite memory efficient because all those dependencies are common to any KDE application. this phenomenon occurs because unlike windows or OS X in linux don't have an unique desktop/framework[note windows do this too but hidden that is why office opens so fast is all preloaded]. so you should compare banshee and amarok running in their native enviroments and in the case of mono reading the memory of the process tree not the application. this same concept have flooded nvnews[<-- nvidia] forum for years with "OMG X11 uses 500MB of memory driver bug driver bug".
    11.) C/C++/obj C are the same family of language with certain variation of concepts but normally you can mix the 3 of them transparently and the syntax is quite common too[since both started from C] and C/C++/objC are used by 90% of the most badass developers in the world and are the supporters of modern computing from kernels to mono/.NET innards and are used to solve in the most efficiently possible way the most complex task in the world. like i always ofc for pops and moms fast consumption facebook client is overkill[C#/python/java/etc are more appropiate for this tasks]
    12.)"C# doesn't have even close to the level of support C++ does, to this day" this one is true but is more complex than you think, remember C and variants runs the world literally from microcontrollers in every industry in the planet to the most massive supercomputers/clusters going all the way to experimental neuronal networks without let slip the most efficient databases systems know to man and you favorite OS too and is massively supported by every major technological company in the planet[IBM/cray/oracle/microsoft/apple/HP/etc.], so you have very nasty set of proven tools commercially/open at you disposal and support in any way you like it, C# is still too young and is officially supported on 1 plataform only[windows][mono is very niche still] and is mostly used as the next generation visual basic fast food language and is too resources expensive to run outside the "PC"/highend smartphone realm nor is well received as parallel language either or properly supported in super computers/clusters since is still too young.

    like i said the problem with mono is not that is bad or anything like it, is a decent high level language good for high level language needs, the problem is that in linux we have already good high level languages that just need to improve performance[python over llvm is FAST but is still out of tree sadly] that wont require any rewrite at all unlike migrate to C# and C# beside being easier to learn/code don't provide any sort of improvement that justifies rewrite the other 96% of the regular distro code that is already in C/C++/objC/ASM. so is kinda stuck in a limbo or a very niche position at best. another factor is that your regular linux developer dont like "assemblies hidden functionality" too much, we preffer hard visible linking and bindings[if you investigate you will notice this pattern over and over again in every high level language that is born in linux]. so mono has ended as being the wine for .NET code[and literally with wine] nothing else and since most distros don't even include mono or just have very old unmaintained versions didn't help the cause either but again the problem is mono just don't fit in linux as concept [and microsoft backing doesn't help nor microsoft care as long mono work as shield for EU sues and reduce taxes]

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •