Announcement

Collapse
No announcement yet.

Mono 2.11.3 Packs In Microsoft's Entity Framework

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • frantaylor
    replied
    Originally posted by halfmanhalfamazing View Post
    But the road is still free. And not only that, they gave you the blueprint on how they built the road, which exactly is what all of us keep asking for. Isn't it?
    " they gave you the blueprint on how they built the road"

    WHAT do you PRESUME we are "asking for"??? The road to Microsoft's virtualization technology? NOPE!! The road to "entity frameworks"? NOPE!!

    These are roads to NOWHERE.

    Microsoft has been publishing "open-source" examples and glue code for DECADES. It's ALL to PUSH THEIR PRODUCTS. It's no more "generous" than Walmart's driveway.

    Leave a comment:


  • halfmanhalfamazing
    replied
    "I like open source, just not THAT open source"

    Originally posted by frantaylor View Post
    .
    That would seem to be a summary of what you just said. All open source is equal, but some open source is more equal than others.

    Has ANYONE bothered to notice that Microsoft's "contributions" are USELESS unless you are working with MICROSOFT products???
    Sure, it seems logical actually. Just like British cars generally stay in Britain. Ever noticed how it will get someone's attention if you have your steering wheel on the right hand side?(I'd imagine the same would be said for having the driver sit on the left hand side, for an Englishman)

    Now of course in recent years things have changed, where those cars are now built in America.(Driver on the left, though)

    At some point, the code will have the same outcome. Why wouldn't it? Open source is on an upward trajectory.(no matter how slight it may be, it's less slight now than it was say 5-10 years ago)

    Besides, I would imagine that most open source programmers on the linux side would take the position that "I'm not using that". I wouldn't either.

    You don't have to pay a toll to use Wal-Mart's parking lot, nor the access road! How GENEROUS they are! LOOK at all the FREE roads they build!
    I think generosity was the last thing on their minds. But the road is still free. And not only that, they gave you the blueprint on how they built the road, which exactly is what all of us keep asking for. Isn't it?

    Something that a lot of people around here should consider is the change of culture:

    Just as a lot of people on the linux side have blind irrational hatred of anything microsoft, even this - there's aversion among users of the other side.

    If Microsoft themselves is opening up it's sources, that will inevitably soften the stance of the closed sourcers.

    How could it not? Getting them to switch to Linux will be still be a hard task, but at least the wall is being broken - and by Microsoft themselves.

    Leave a comment:


  • frantaylor
    replied
    misguided

    This is certainly a step in the right direction. Even they see the light: Open source is the future.
    Has ANYONE bothered to notice that Microsoft's "contributions" are USELESS unless you are working with MICROSOFT products???

    You don't have to pay a toll to use Wal-Mart's parking lot, nor the access road! How GENEROUS they are! LOOK at all the FREE roads they build!

    Leave a comment:


  • frantaylor
    replied
    Entity framework = huge albatross

    "Entity frameworks" are nothing more than pure bloat.

    If you need an "entity framework" it's a symptom: you are not doing it right.

    Use a database with semantics that match your application, and you don't need no steenkin "entity framework".

    How nice of Microsoft to encourage bad software design.

    Leave it to Microsoft to come up with designs like this:

    - developer wants to store key-value pairs

    - "entity framework" creates SQL queries to model "key-value" store

    - SQL database parses SQL queries and performs "key-value" operations on its underlying database.

    So here we have creation of SQL code and the subsequent parsing of this SQL code for NO REASON WHATSOEVER.

    Yee-haw!
    Last edited by frantaylor; 14 August 2012, 11:29 AM.

    Leave a comment:


  • ciplogic
    replied
    Originally posted by moonlitfire View Post
    Comparing PHP with a good opcode caching implementation vs Mono or .Net might be a bit more interesting. I feel that there is no real comparison between them as is though. Raw performance goes in favor of the mono .Net platform, but it isn't always about that. 9 times out of 10 I end up having to stick wordmess on a server, get the clients small website up, and be done with it without too much thinking. It ends up being what the clients want, and PHP is almost always the platform their cheap hosts already provide.
    Yes, I think that most of Mono folks agree. And this also applies with other slow language implementations which are usable and powerful: Ruby on Rails, Python/Django. For desktop applications happen the same: Mono as of today is not packaged to do Gtk3 development, when Python is, and most of tooling in a distribution as Fedora may be a mix of Python (like Anaconda setup tool) and C.
    And also I think most Mono folks agree that optimized C++ can be a bit faster. What was really wrong was the idea that virtual machines in general are interepreted. As of day of writing, there is no JavaScript VM that does not compile hot portions of code.

    Leave a comment:


  • moonlitfire
    replied
    Comparing PHP with a good opcode caching implementation vs Mono or .Net might be a bit more interesting. I feel that there is no real comparison between them as is though. Raw performance goes in favor of the mono .Net platform, but it isn't always about that. 9 times out of 10 I end up having to stick wordmess on a server, get the clients small website up, and be done with it without too much thinking. It ends up being what the clients want, and PHP is almost always the platform their cheap hosts already provide.

    Leave a comment:


  • Kristian Joensen
    replied
    Originally posted by jrch2k8 View Post
    sadly nope, microsoft did this not for the goodness of their heart or cause they believe in open source[they not], they do it for this reasons:

    1.) to add value to the closed source version[which has more features and is windows only btw] so they can say .NET is not windows only and you can use it in other OSes[which is very unlikely to happen since mono is quite behind] but is good for PR.
    2.) to avoid monopoly lawsuits in euro zone cuz .NET is "open source" and again good for PR.
    3.) xamarian works good as charity to deduce taxes and as troy horse[in theory cuz .NET outside windows is less than non existant].
    4.) possible patent wreck in the future when they need to milk some cash from big sharks that migrated to Mono [they say no but microsoft is well microsoft]
    5.) avoid migration to other toolkit/languages promising "multiplataform greatness" so they can keep milking you in windows[dubious advertisement but most sysadmin in bussiness arent the sharper knife of the box]

    I get your worries about this and I would be inclined to share them about Mono in general but not with the entity framework since that is available under the Apache License 2.0, a widely used FLOSS license not written by MS, approved by both the OSI and the FSF, compatible with the GPLv3 that has a patent grant.

    Leave a comment:


  • F i L
    replied
    Originally posted by ciplogic View Post
    JIT is not an interpreter! Is a Just-In-Time compiler. Also .Net is a platform (which includes a VM, that is in case of .Net a JIT, and in case of Compact Framework an interpreter). The JIT generated code is as hard (or as easy) as any C++ code, and the base code is as hard to decrypt (if you mean the the .Net's bytecode that defines the programs, there are many obfuscators to make sure that no one can read them).
    When we talk both about .Net and about Mono, because they are not interpreters, they can generate output of the program which is fully compiled (as .so on Linux, and as native .dll on Windows) that is used to execute the code you are running.
    There are many cases when .Net code works in the same performance range as it would be written in a native language, like Paint.Net/Pinta, sometimes they may work even faster (MonoDevelop/SharpDevelop in .Net/Mono world, or Eclipse/IntelliJ IDEA) than their opensource equivalents (Adjunta, DevC++), sometimes slower (in Java world, comes Netbeans to mind, even though Netbeans improved a lot the performance in the last releases).
    In the list of languages, I'm really familiar with Pascal, and I can say that is not faster than C# on Linux. FreePascal is basically tied performance wise (even though memory wise Pascal seems to be the most efficient of all): http://shootout.alioth.debian.org/u6...l&lang2=csharp Anyway, I'm thinking that statically compiled with LLVM may run faster on phones (like Mono for Android or for iOS) than the FreePascal equivalent. The reason is because Mono can be compiled into optimized code, and FreePascal has a more limited optimizer (is in the same class as the JIT of Mono, it performs a bit more optimizations, but it has no good registry allocator).
    At the end, did you tried in your real applications to use Mono? To see if is fast(er)? Are you using just XSP and based on this you make up your mind?
    As for my machine, I did precompile most of applications on Mono (search for AOT = ahead of time compilation), to reduce startup time, but performance wise otherwise is really unoticiable (I think it should be faster in JIT mode).
    Do you have any numbers when Mono is slow to you?
    To add to this, Mono .NET supports SSE compiler intrinsics, which, if used property (and this is the kicker) can get close to the performance of C++ for game maths. That being said, they're only currently supported on Linux and Mac (no SmartPhones, sadly), and unless you use the Mono.Simd vector types directly (can't wrap into custom struct) your performance drops significantly. The big problem with this is that some common operations are not supported on these:

    Code:
    Vector4f a; // Mono.Simd vector type
    
    a *= 5; // works
    a += 5; // doesn't work
    a += new Vector4f(5); // works
    That being said, if you are willing to live with the quarks and limitations, vector math written with Mono.Simd on Linux/Mac runs ~2-6 times faster (depending on the CPU) than anything MS .NET on Windows can dish out, and gets similar (be not quite as much) performance as native C/C++ applications in this area. SIMD operations are a game changer for Games, so it's nice to note that on Linux, games written with .NET have a distinct advantage.
    Last edited by F i L; 13 August 2012, 08:19 PM.

    Leave a comment:


  • halfmanhalfamazing
    replied
    Originally posted by jrch2k8 View Post
    the problem is the only they has given is code [apache/bsd licenses i think] and the promise they won't sue you to death cuz they own the patents and copyrights and they havent let those go or make any attempt to add them to a patent protection pool[at least as far i looked] so the risk is always there
    Hasn't that theory been tested though?

    They put themselves in a bad position of open sourcing something. Then to proceed to suing anybody for using it, isn't that a bit of pandora's box going on?

    I would think that some Google/Java/Oracle applies here. Microsoft might be able to say to another company that you can't use this, but for users out in the wilderness, I don't see where they'd have ground to stand on. It would be clearly predatory, and I couldn't see a jury in the world that would indict.

    Leave a comment:


  • ciplogic
    replied
    Originally posted by jrch2k8 View Post
    .NET is not a compiled language is an interpreted language with a packer and a JIT VM[thats why is so easy to dissasemble] thats why you need to keep the .NET framework everywhere[in the case of ASP.NET the framewrok is called from IIS].

    php is another interpreted language but without packer aka you cannot create a .EXE with it but i beg to differ with you here since PHP has API to do almost everything an OS can do LOL[at least in linux] through plugins[you can even call ffmpeg api from php]

    in my experience .NET is not faster than c/c++/pascal/cobol/fortran[<--- real compiled languages] nor seen ASP.Net code faster than PHP+nginx [would be interesting to show some use cases where you find aps been faster than php][or you mean on windows? in that case is possible]
    JIT is not an interpreter! Is a Just-In-Time compiler. Also .Net is a platform (which includes a VM, that is in case of .Net a JIT, and in case of Compact Framework an interpreter). The JIT generated code is as hard (or as easy) as any C++ code, and the base code is as hard to decrypt (if you mean the the .Net's bytecode that defines the programs, there are many obfuscators to make sure that no one can read them).
    When we talk both about .Net and about Mono, because they are not interpreters, they can generate output of the program which is fully compiled (as .so on Linux, and as native .dll on Windows) that is used to execute the code you are running.
    There are many cases when .Net code works in the same performance range as it would be written in a native language, like Paint.Net/Pinta, sometimes they may work even faster (MonoDevelop/SharpDevelop in .Net/Mono world, or Eclipse/IntelliJ IDEA) than their opensource equivalents (Adjunta, DevC++), sometimes slower (in Java world, comes Netbeans to mind, even though Netbeans improved a lot the performance in the last releases).
    In the list of languages, I'm really familiar with Pascal, and I can say that is not faster than C# on Linux. FreePascal is basically tied performance wise (even though memory wise Pascal seems to be the most efficient of all): http://shootout.alioth.debian.org/u6...l&lang2=csharp Anyway, I'm thinking that statically compiled with LLVM may run faster on phones (like Mono for Android or for iOS) than the FreePascal equivalent. The reason is because Mono can be compiled into optimized code, and FreePascal has a more limited optimizer (is in the same class as the JIT of Mono, it performs a bit more optimizations, but it has no good registry allocator).
    At the end, did you tried in your real applications to use Mono? To see if is fast(er)? Are you using just XSP and based on this you make up your mind?
    As for my machine, I did precompile most of applications on Mono (search for AOT = ahead of time compilation), to reduce startup time, but performance wise otherwise is really unoticiable (I think it should be faster in JIT mode).
    Do you have any numbers when Mono is slow to you?

    Leave a comment:

Working...
X