Revolt of the “Independent” Software Vendors

For decades, M$ has enslaved all of its customers, “partners” and ISVs (Independent Software Vendors). They have all been enlisted to prop up the monopoly in PC operating systems. The ISVs, while supposedly independent, were made dependent by offering “inside information”, special APIs to give advantages over competitors, lots of software-creation tools and, of course, backwards compatibility. M$ did not do any of that to aid ISVs but to aid M$.

Now, M$, inspired by Apple’s success in making walled gardens lucrative, is shortening the chain of ISVs making applications for “8”. As observed by Rex Djere,

“the openness of GNU/Linux is becoming very attractive to PC game developers as the see the Windows 8 market coming”.

Some ISVs will see M$’s “market” as a tax they don’t need to pay when there’s no such tax on GNU/Linux operating systems.

see TLWIR 43: You Know That the GNU/LInux Shift is Coming When the Eggheads Start Conspiring.

Prices may not be sufficient motivation for gaming ISVs to shift allegiance but performance is hard to beat. Do gamers want their PCs searching for malware on every seek or phoning home? I doubt it. Restrictions on applications for “8” could be just the beginning of the end of independence and game developers don’t need or want M$ managing their businesses.

Many other sorts of applications may draw their ISVs into this revolt. ISVs that recently looked upon that other OS as a licence to print money may well see that dependence as a ticket to being uncompetitive. After all when Android/Linux is hot and GNU/Linux heating up, no ISV wants to be shut out of new markets which could be several times larger than Wintel. The world loves small cheap computers and ISVs need their applications to run on them. “8” won’t be a ticket to ride.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology. Bookmark the permalink.

53 Responses to Revolt of the “Independent” Software Vendors

  1. ch says:

    “users of GIMP who cannot afford PS”

    The version reviewed – PS Elements – retails for €73. If someone can’t afford that, how can he afford a computer in the first place?

  2. Brillo says:

    …or not. I have introduced GIMP to thousands and not one found the adventure painful.

    Lemme guess. You means “thousands of students who have no choice but to sit in front of the thing and fake a smile at you until they can go home and play CoD on their XBox”.

    I was also a kid once, you know.

  3. ch echoed, “If you want to use GIMP, you should have a high pain tolerance.”

    …or not. I have introduced GIMP to thousands and not one found the adventure painful. How does PS induce pain in users of GIMP who cannot afford PS and have never used it? That’s silly. GIMP has a GUI. A lot of it is self-explanatory and most ordinary folk with a digital camera or scanner can do everything they need with GIMP. That said, I still prefer ImageMagick for a lot of work. e.g. yesterday, the little woman found Kijiji inverted an image. I inverted it for her with a single command and Kijiji turned it right side up. It was an ad and the item sold within hours. FLOSS works.

  4. ch says:

    Correction: “PS Essentials” is really named “Photoshop Elements”.

  5. ch says:

    Here in Germany, there s a computer magazine called c’t – think of it as a German version of the late BYTE magazine (in fact, for some years the two cooperated). It’s very competent, reliable, and though the staff likes to look at everything FLOSS and Linux with slightly rose-tinted glasses they are too professional to let that bias color their reviews.

    So in their last round-up of sub-€100 image manipulation programs, PS Essentials was way ahead of the rest, some of the rest had interesting features – and the poor GIMP came out second-to-last only because they included Paint.NET. Remarkable quote from the review: “If you want to use GIMP, you should have a high pain tolerance.”

  6. Clarence Moon says:

    a product for a very narrow niche

    You are slowing beginning to think a little more clearly, Mr. Pogson, and that is a good thing. Certainly PhotoShop is a product that only appeals to a narrow niche of users who can take advantage of its features to generate some economic advantage in their work.

    My own, very limited as are yours I am sure, needs are met with Paint Shop Pro which I acquired years ago for either Win2K or XP, I don’t remember exactly, and which still functions just fine with Win7. I think that it was sold to Corell or vice-versa a few years ago.

    If you are really in the business of graphics design, you will use PhotoShop, most likely on a Macintosh computer. If you are just chipping, you might even use Gimp, but I bet most Gimp users use it with Windows.

  7. Ted wrote, “a professional graphics artist”.

    So, Ted admits that PS is a product for a very narrow niche. In my whole life I have only met professional graphic artists back in high school, decades ago. There aren’t that many of them…

  8. Ted says:

    “PS costs $699 up to $2600 depending on feature-set.”

    This is just being dishonest, and spinning numbers in your favour.

    Photoshop CS6 itself costs $699 or $999. The scary sounding $2600 you quote is for the Master Collection bundle, which contains Photoshop and about 10 other separate complete applications, most of which work together.

    “GIMP is proof that PS is not essential. I certainly have no use for it and I am a professional.”

    But you are not a professional graphics artist.

  9. Dr Loser says:

    Look, I’m really sorry about this, Robert.

    Regarding “.Net optimization,” which appears to be yet another Oiaohm fantasy without attribution.

    One of the things that annoys me about working with C# (what with me being a C/C++ guy and all) is the almost complete lack of compiler options for optimization.

    That said, read this from the horse’s mouth, as it were.

    I suspect, though I am open to being proved wrong, that Oiaohm is crediting the .Net compiler with far more of an aggressive optimizer than it is capable of.

  10. Dr Loser says:

    For completeness, and here I will admit that I was wrong, here is a list of JVM bytecodes.

    Note that there is (and I am wrong) a single bytecode that references casting.

    checkcast … C0 … “checks whether an objectref is of a certain type, the class reference of which is in the constant pool at index (indexbyte1 << 8 + indexbyte2)"

    I freely admit that I have no idea what this is used for. It might be used to attach type information to Java generics, although I doubt it, because all the necessary upcasting and downcasting has already been determined by the compiler. But still. It might be.

    I suspect, but have no evidence, that it is in fact intended for use with runtime type-checking, otherwise known as dynamic typing.

    The desirable properties of (nonexistent in current Java or JVM) reified generics are well summarised here.

    Now, you can read through as much of this stuff as you care to (and it’s more than I cared to, although I enjoyed it as a purely intellectual exercise) and you will never, I repeat never, come across an instance where const cast, static cast, reinterpret cast, or c-cast are part of JVM bytecode. (The alert reader will spot the missing beast: explained below.)

    See, there are only 220 or so of the things. Kinda limiting.

    Regarding which, Oiaohm, I wish to point out yet one more egregious misunderstanding of your own links:

    C-Style Casts with slash-clr

    Yes under CLR C and C++ are mapped up same you do under Java.

    You do realise that /clr is a parameter passed to the .Net compiler, don’t you? You do realise that it has no bearing whatsoever on typecasting information in the resultant bytecode, don’t you? You do realise that it cannot possibly do so, because the resultant bytecode doesn’t understand typecasting? You do realise that (JVM or CLR) this is intentional, don’t you? You do realise that this is the entire point of having a compiler (Java, C#, Pascal, whatever) in the first place, don’t you?

    Well, perhaps not.

    Incidentally, you never got back to me on that “exceptions” thing, possibly because you have never programmed in a language that features exceptions. Here’s the thing about exceptions and type casting and type safety (Ourobouros be praised! We round the circle!):

    The basic reason for typecasting in either C# or Java is either to upcast or to downcast..

    Both upcasting and downcasting are invisible to the respective bytecode sets, and do you want to know why?

    Because they operate at a higher level, that’s why. The only thing that cares about upcasting and downcasting is the Java or .Net runtime. Not the bytecode.

    And do you want to know what happens when (either) runtime detects an inadmissible upcast or downcast?

    It throws an exception, that’s what happens.

    It’s an almost completely different approach to C/C++ style typecasting, and I was hoping that you would notice that.

    The only part of C++ typecasting that has any remote relevance to any of this is the dynamic cast, which does pretty much the same thing.

    Hey, I hang targets out to dry, and all you can do is to claim that serializing one type and deserializing it into a random unrelated type constitutes “type safety” in Java.

    I mean, I’m a big ole fat target here. Is that the best you can manage?

  11. DrLoser says:

    One last quote, then.

    Serialization is the is the normally Java replacement for Reinterpret cast.

    No it no it isn’t isn’t, not no never.

    Is there no end to the stupid things you can make up, Oiaohm?

  12. DrLoser says:

    I’ve wasted too much of Mr Pogson’s time with this (please note that I am being platform-neutral here. Linux and Windows both good, Java and .Net both good, JVM and CLR both good), and Oiaohm point-blank refuses to correct his argument or to provide a single useful link.

    After the approach of Phenom, therefore, I will choose a single malapropism amongst many to highlight, and then I’m off.

    The thing here same like keywords does not equal same function. You GC a list in .net what you shove into it is not type checked all the time.

    You GC a list in JVM it is type checked always. I am referring to byte-code processing differences. Allocated by Garbage collector does not mean you record the type of the object you just allocated for future usage to prevent errors.

    What part of “It’s a list of (references to) Sports Cars” do you not follow? The bit where the CIL declares a list, or the bit where it declares the generic parameter as Sports Car?

    Do you know what the equivalent is in Java bytecode? It’s a list of Object. That’s how Java implemented generics: a reference is a reference, and an instance of any class can be upcast to Object and downcast again (note the correct use of the term casting here).

    Is JVM therefore type-unsafe? Of course it isn’t. It carries less type information than the equivalent CIL, but that doesn’t matter because the compiler did it for you.

    Curiously, this is the exact opposite of what you seem to believe. Weird, isn’t it? I am (correctly) defending Java type safety in precisely the same terms you (incorrectly) attack .Net type safety.

    And nothing is ever “allocated” by either garbage collector. For the love of God, get your terminology right. In this case it is quite important, because allocators in both languages are fully aware of the type whose instance they are allocating.

    To repeat, this knowledge persists in CIL even when passed into a generic container. The fact that it does not persist in JVM bytecode has a few unfortunate side-effects in terms of reflection and forced boxing of native types, etc, but at the bytecode level it is irrelevant.

    A reference is a reference is a reference.

    Everything else you say on this subject is pure nonsense. Your link (Java 6.0) does not, in fact, demonstrate anything like what you think it does. It simply shows that the JVM (correctly) retains enough information in a parameter list to enforce generic type safety.

    It would be pretty catastrophic if it didn’t, wouldn’t it? You’d lose all safety when accessing the public classes of a separate compilation unit.

    Looking into the bytecode in the hexdump, however, what is actually happening is that the JVM is storing a label in its string pool. This label is:

    Ljava/util/list<Ljava/util/string;>;

    It isn’t a type: it’s a label. Once again, I believe that this is what you were complaining about where .Net is concerned, so I am sure you can tell the difference.

    All Java generic containers are parameterised by Object, no matter what you say. This extends to the byte code, by definition. It is an inevitable consequence of type erasure (Wikipedia chosen for your convenience).

  13. oiaohm says:

    DrLoser
    “JVM via the keyword and destructed by the GC (of course). In a semantically identical way, they are constructed by the CLR via the keywords newobj instance (It’s in the example, if that helps.) and, gosh, destructed by the GC.”
    The thing here same like keywords does not equal same function. You GC a list in .net what you shove into it is not type checked all the time.

    You GC a list in JVM it is type checked always. I am referring to byte-code processing differences. Allocated by Garbage collector does not mean you record the type of the object you just allocated for future usage to prevent errors. To be a JVM the type must be recorded for future compares and will be compared to. For a .net runtimes recorded yes but only sometime compared and in optimised .net code sometimes not even recorded what type instead generic catch all recorded. newobj in .net will accept a generic catch all type, init in jvm will not. This is a behaviour difference. Important behaviour difference.

    Creating the objects is not where the problem comes in. Using the objects and having them accept miss matched types is where hell breaks lose.

    DrLoser
    “And here’s a hint on which ones are relevant to the JVM and/or CLR … oh, I can’t be bothered hinting. None of them.”

    Wrong answer completely wrong. Const cast, static cast and dynamic cast exists in java byte code.
    Reinterpret cast and the C type casts are missing. Serialization is the is the normally Java replacement for Reinterpret cast.
    Then there is generic cast that is unique for being always enforcing to JVM 6.0+ and related. Existed prior in java sdk 5.0 generated bytecodes just not used.

    http://msdn.microsoft.com/en-us/library/8d3h6t9s%28v=vs.110%29.aspx
    Yes under CLR C and C++ are mapped up same you do under Java.

    Really this just proved to me you don’t know CLR or JVM bytecodes at all because you flat out claimed no type cast in them when there is. People who have only read CIL source get the stupid idea they are not required or in some cases of complete level of idiot that they don’t exist for .net. Yes MS C# complier has a bad habit of not creating them when it should.

    This is the problem DrLoser lot of .net defenders don’t know that a CIL file should contain a lot more casting defines than it does to make it secure. .Net runtime supports sloppy code. JVM run-times not so friendly.

    Listing C++ cast types was not related to the problem being talked about. I said this because you asked the wrong question completely DrLoser.

    I said I got type cast from C++. I was been mean. C# and Java get the term type cast from C++.

    Brillo
    “Generic types (or generics) bear a superficial resemblance to templates in C++, both in their syntax and in their expected use cases (such as container classes). But the similarity is only skin-deep — generics in the Java language are implemented almost entirely in the compiler, which performs type checking and type inference, and then generates ordinary, non-generic bytecodes.”
    This is 2005 documentation old and out of date. You have to remember IBM had there own JVM back then.

    Java 5.0 had a bug that caused it to throw warnings on valid code.

    Java 6.0 and later different story. http://alaindefrance.wordpress.com/2009/10/28/generics-inside-byte-code/
    Brillo that shows a Java 6.0 class showing the generics information. So we are not talking only compiler processed any more. At Java 6.0 is Complier and JVM. Java 5.0 it would throw warning messages on valid code due to JVM 5.0 not having enough detail to know if action was safe.

    Even in Java 5.0 you find the generic recorded in the bytecode in lots of cases. Just the Java 5.0 JVM does not use it causing some major migraines by spitting out warnings at runtime over nothing. The Java 6.0+ JVM on the other hand will fail if it missing in a lot of cases due to the warning now being a error. This fact caused a lot of screaming by people who had stacks of Java 5.0 code and had run third party optimisers that had stripped out the generic notes in the bytecode. Worked fine with JVM 5.0 completely failed with JVM 6.0. Implications of erasure was addressed JVM 6.0.

    December 11, 2006 Brillo is JVM 6.0 That is still a long time ago.

    This is the problem generics in a JVM bytecode its in the bytecode. Its not something the complier solves out of existence.

  14. Adam King says:

    Notice how the winbreds have a special fondness for the mentally defective with all their talk of “average” users and grandmas. Companies like M$ exploit the mentally defective for financial purposes and M$ $hills exploit the mentally defective for their own physical gratification. The illegal monopoly is a truely sick entity.

  15. DrLoser says:

    generated by the compiler…

    Strictly speaking, fully-specified by the compiler, but generated by the CLR on the fly (using a cache where possible).

    I know this and you know this, but I find it important when talking to Oiaohm to be painstakingly accurate.

    Speaking of whom:

    The CIL down the bottom of the page is not a complex example.

    And yet you still fail to understand it. I put effort into finding the simplest example possible, with the constraint that it doesn’t feature native types (which might be considered a cheat in some way).

    If it’s impossible to get the point across to you by using the simplest possible example, what use would I have for a more complicated one? Oh, and by the way, the more complicated ones work by composition, which is to say that they can be broken down into simple examples. This would be true either in the JVM or in the CLR.

    Anyone can google and find the list of C++ type casts. This really is where the term comes from and really has no bearing on the problem at hand.

    You haven’t defined the problem, so it’s impossible to judge bearing or otherwise. You have, however, persistently confused typecasting with type safety, and quoted C++ as a reference point.

    It’s not unreasonable to ask for exposition here. Remember, I also asked two further, complicated, supplementals: which ones are supported in the JVM/CLR, and are any of them dangerous from a type-safety point of view?

    Perhaps you can return to that minor issue.

    Just so we’re on the same page, and wholly without googling, there are five:

    1) Const cast
    2) Static cast
    3) Dynamic cast
    4) Reinterpret cast
    5) C-style cast, although that turns out to be whichever of the four above is appropriate. Just for completeness, though.

    And here’s a hint on the type safety thing: consider exceptions.

    And here’s a hint on which ones are relevant to the JVM and/or CLR … oh, I can’t be bothered hinting. None of them.

    That’s right. Neither the JVM nor the CLR has a mechanism for type casting.

    I wonder, therefore, why you persist in bringing this nonexistent subject up?

    Lot of these errors show weaknesses in the CLR like getting type of some object wrong because it has not had activated yet.

    “Activated”? Linky please. Objects (more precisely, references to objects) are constructed by the JVM via the keyword <init> and destructed by the GC (of course). In a semantically identical way, they are constructed by the CLR via the keywords newobj instance (It’s in the example, if that helps.) and, gosh, destructed by the GC.

    Making an entire meta-language up to describe what is going on is not going to help you here. Links might. (But not when they don’t exist.)

    At this point you are going what has happened to my poor program because nothing is behaving right. Yes save some cpu don’t perform a class check and things can go badly wrong.

    Aside from the bizarre anthropomorphisation, it’s your program, isn’t it? Have you considered debugging it?

    Now wrong wrong files link up nice miss match causing random error somewhere.

    That’s assemblies (or in Java classpaths/JARs), Oiaohm. It has absolutely nothing to do with the safety or otherwise of the respective bytecodes.

    DrLoser already put up the link on data-flow analysis required.

    What, the front page to a company website advertising their product? I think not, Oiaohm. I need a better link than that. It doesn’t matter whether it’s a FLOSS company or a commercial company: either one is motivated to sell you snake-oil.

    DrLoser reading csharp documentation will not help you understand the difference at all.

    I didn’t read or quote a single page of C-sharp documentation, mate. I read JVM and CLR documentation, plus samples and tutorials.

    This is the generally accepted method of backing your argument up with facts. It requires a certain technical diligence, but it’s an unavoidable effort.

    Unless, of course, one relies on looking up keywords in Google, pulling things out of thin air, repeatly misusing well-understood terminology, and sheer empty bombast.

  16. Clarence Moon says:

    For every “professional” who cannot do his job without PS, there are thousands of amateurs who don’t need it at all thanks to other software such as GIMP

    I can agree with that, of course, but you should have said “such as Paint Shop Pro” to be more accurate.

    I certainly have no use for it and I am a professional.

    Surely not a professional computer graphics provider, Mr. Pogson? You have bragged elsewhere of your being a gravel spreader and mower oiler. Is there any FLOSS support for those professions?

  17. Phenom says:

    Spam filter at works. Probably it doesn’t like escaping HTML characters.

  18. Phenom says:

    A single excerpt from Ohio’s wall of text:
    ‘List`1′ << This label stuff is what .net vm is running by. Not the type.

    List`1 is a new type, generated by the compiler for your declaration of List<SportsCar>.

    CRL actually runs that particular type, and nothing else.

    Ohio, why don’t you simply give up and try to save the tiny leftovers of your dignity?

  19. oiaohm says:

    DrLoser already put up the link on data-flow analysis required. You can got there CLR and you find it missing. xmlvm does not do data-flow analysis converting from jvm to CLR. If you try to improve xmlvm to improve its conversion speed you simply find out it lacking the required information.

    DrLoser
    “No, it’s because the ex-Ximian guys have had ten years’ experience and got it right. They’ve got the figures to prove it.”
    Figure without understanding what the differences are in the two bytecodes are pointless.

    Due to the fact only JVM and related engines do it there is no formal name for it. type cast the term type checking engine is another that can be used. It not what people call type safe. type safe is a sloppy term as long as what the complier did its type safe not what happened the linker and optimisation stages. In fact type cast is correct storage as set type value even when blank.

    C++ has many type cast in a C++ file. JVM and related have type cast in the byte code. There are of type casting that type cast can be used to define.

    Doing type checking at runtime on most operations cost cpu time.

    DrLoser reading csharp documentation will not help you understand the difference at all. I am not talking about csharp or java. I am talking about there bytecodes. How those bytecode operate.

    The CIL down the bottom of the page is not a complex example.
    “callvirt instance void class [mscorlib]System.Collections.Generic.’List`1′ ::Add(!0)”

    If you were to mess with this line change that class. Would it run yes it would until it got to
    “callvirt instance int32 class [mscorlib]System.Collections.Generic.’List`1′ ::get_Count()” No sometimes this will work as well.

    So now you have a object that you think only contains SportsCar but it contains bits of other things as well.

    Then the program could fail with .net. Same thing in jvm is going to fail as you do the first miss match.

    What is saving your ass with .net is the complier working. Also when you know what ones you can delete you can delete lots of the references. Makes your program smaller with .net harder to disassemble. The reason why you can delete them is the bytecode engine does not depend on them to work.

    Highly optimsied .net program converting the CLR you are going to find a lot of that missing. Because declaring the code as generic it will take anything code path is smaller in bytecode in .net and works the same other than no run-time safety and now a lot harder conversion to java. Now wrong wrong files link up nice miss match causing random error somewhere. So you can hit a program in .net where there is basically no declares at all. Where almost everything is generic at bytecode level. Say hello Pandora box. Its one thing to have a type safe coding language its another to go “Ok at byte code we will forget recording type it will work we hope the libraries and so on that we care calling keep on returning the types we expect” This is what you find inside .net programs. Sections of code depending on outside parts to set what type of storage they are then having interacting between those types.

    ‘List`1’ << This label stuff is what .net vm is running by. Not the type. Jvm when you create a new object its type is recorded. This type is used to check if any future operations on that label should be allowed.

    DrLoser it is a small critical difference. Before Java 7 there was no ie match target class or true full blowing generic at bytecode level. .Net has had a full blown generic at bytecode level.

    Possibly in time we will see some optimisers exploiting in Java 7.

    Even more strange is some version of .net don’t even error. The miss match of the class disappears into the void. So access the label like ‘list 1’ using get one result access ‘list 1’ using get a different result. So two difference class same name equals two different storage. Sometimes that will just fail out right.

    It will all depend how the generic class in .net you interface with is designed if what you do fails or works leading to strange errors. Java it fails very predictably.

    At this point you are going what has happened to my poor program because nothing is behaving right. Yes save some cpu don’t perform a class check and things can go badly wrong.

    data-flow analysis on a .net bytecode should come back perfectly sane. It is the ones that don’t are where complier as screwed up.

    DrLoser
    “There, you are absolutely correct. In a mathematical sense, JVM bytecode is a strict subset of CLR bytecode.”
    In fact no. JVM can convert to CLR but it has dropped data in the process. Information that the JVM uses by the .net runtimes don’t. They are over lapping sets in a mathematical sense. Each with some of there own area. Some of the unique area of a JVM is the runtime type checking on the java generic functions. So prevent a stack of strange errors.

    In fact some JVM bytecode ported to CLR will fail because CLR handles things incorrectly for a JVM. Lot of these errors show weaknesses in the CLR like getting type of some object wrong because it has not had activated yet.

    DrLoser
    “There are definitely easier ways to introduce bugs if all you are dealing with is a raw stream of byte code.”
    There are a lot of places errors can enter a raw stream. Read errors memory errors …. So there are very valid reason to be checking.

    This part I am talking about is only one part of the process a JVM is checking for errors. Split bytecode verification and other runtime verifications are done as well. JVM is very distrusting of the bytecode it has been given. .net on the other hand is very trusting of the bytecode it has been given. So a lot of support data a JVM bytecode needs a .net does not.

    Anyone can google and find the list of C++ type casts. This really is where the term comes from and really has no bearing on the problem at hand.

    DrLoser reality you don’t want to have to accept there is something unique about JVM and related engines that .net does not have. That unique bit gives some advantages it does have a price performance. You cannot perform more security checks and be faster.

  20. Clarence Moon wrote, of GIMP, “it is a mere curiosity, known only to a few hard-core FLOSSers. For the casual user, I would wager that Paint Shop Pro has orders of magnitudes more followers than Gimp.”

    For every “professional” who cannot do his job without PS, there are thousands of amateurs who don’t need it at all thanks to other software such as GIMP. Check Adobe’s revenue and divide by the licensing fee to see that only a small fraction of PCs get PS. Most people don’t need it because they don’t work for print magazines etc. or use $10K printers. The hundreds of millions of digital camera, tablet and smart phone owners post images to FB or e-mail them to friends. No need for PS’s bloat for most of that. That some professional people do use GIMP is proof that PS is not essential. I certainly have no use for it and I am a professional.

  21. kurkosdr wrote, “When you will discover “software freedom” is a set of four arbitary commands written by a loon, and presented as something the world must follow no matter what “.

    Wrong on a bunch of points. Software freedom is not about arbitrary commands. It’s about sharing. Software that is distributed under a FLOSS licence, say GPL, can be used by anyone, examined, modified and distributed. This ensures that the software remains “FREE” which maximizes its benefit to mankind. It’s not about controlling people but setting them free to share, contribute and to help one another. It’s about preventing the monopolization of software. We need only read US DOJ v M$ to see why monopolized software can be used to abuse people.

  22. kurkosdr says:

    “They refuse to recognize the pivital importance of freedom, a concept for which many have died. a”

    Quote a single declaration of human rights that proclaims access and redistribution rights to the source code a necessary freedom.

    When you will discover “software freedom” is a set of four arbitary commands written by a loon, and presented as something the world must follow no matter what (as if the world cares), you will feel dumb for wasting so much time. But like hippies that are searching for an excuse to not work, you will NOT realize the silliness of Stallmans commands unless you abandon your basement-dwelling dumpster-diving, living-on-mom’s-allowance-like-a-10-year-old lifestyle. You are following Stallman’s cult because his theories fit the way you live. It’s better to think that software “should be free” and boycott proprietary software, than think you don’t have proprietary software because you can’t afford it (and you are too much of a tool to pirate it). Much on the same way hippies “boycott” BMWs, Mansions etc. It’s not they can’t afford them, they are “boycotting” them.

  23. oldman says:

    “But when the time comes photoshit will be ripped from them like a rotten tooth from an idiot who refuses to brush.”

    ROFLMAO!

    Who is going to do this Mr. King?

    You, you little pathetic bully?

  24. Adam King says:

    They refuse to switch because to their mind the GIMP doesn’t give them anything. They refuse to recognize the pivital importance of freedom, a concept for which many have died. all they care about is their petty job. They ignore the greater philosophical issues being fought over every day. But when the time comes photoshit will be ripped from them like a rotten tooth from an idiot who refuses to brush.

  25. DrLoser says:

    OK, Oiaohm, you’re almost there. Let’s check off the last list of blatant nonsense.

    This is a lie because reality CLR to JVM cannot be done without running data-flow analysis. Because required information is missing.

    Linky, please. I have a hard time imagining the need for data-flow analysis when moving from a superset of metadata to a subset, ie MSIL to JVM byte code. It’s possible, but I need you to put up or shut up.

    You can covert JVM to CLR without needing any middle processing steps because JVM has extra information.

    Linky please, or I will persist in my belief (along with anybody at all who knows this stuff) that JVM has no extra information at all.

    The simpler conversion of bytecodes is JVM to CLR.

    There, you are absolutely correct. In a mathematical sense, JVM bytecode is a strict subset of CLR bytecode. (Leaving the different approaches to dynamic languages aside. Possibly.)

    As I recall, however, you were talking about converting CLR bytecode to JVM bytecode. Pointless as that might be, even you would admit that there is no possible reason to do it in the opposite direction.

    Being correct does not help you here. The point is moot.

    The complex is CLR to JVM due to CLR striping type information.

    I will here adopt a Socratic rebuttal. I know nothing of this, Oiaohm, and therefore I ask you to instruct me.

    Obviously, I agree, as an expert on the matter, you are entitled to insist that the CLR strips type information. How could I disagree?

    Naturally, therefore, something or someone has to reinsert that missing type information.

    Now, Master, please explain to me how “data flow analysis” achieves this minor miracle.

    See, either your precious data flow analysis needs that type information, or it doesn’t. If it does, you have infinite recursion. If it doesn’t, then it really isn’t type information at all, is it?

    Reason JVM presumes the applications you are processing are possibly hostile and that someone will intentionally try to cause a type miss match to cause a bug.

    I could be wrong, but I’m under the impression that only a raving maniac would depend upon “type safety” to prevent bugs. There are definitely easier ways to introduce bugs if all you are dealing with is a raw stream of byte code.

    This is where people make a mistake. CLR stops at the outside of functions with the information. Sometimes even less. Why because it operates in the presume that everything inside is OK because the compliers said it was ok.

    Sigh.

    I’ve tried my best to find a simple illustration of quite how incorrect this assertion is — “outside of functions?” — and this is the best I can find.

    Look at the CIL in whiteboard 5. That represents a list of a user-defined type, in this case “SportsCar.”

    Does that really look type-unsafe to you? If so, why?

    type cast come from what I called them coding C++.

    Look, I did you the favour of thinking that you mis-spoke and didn’t really mean “type cast.” Apparently you didn’t, and you do. At this point your foot is so far down your throat that, to a casual observer, it appears to be back where it started from.

    An exercise for the Outback Reader: There are five varieties of type cast in C++. List them. Enumerate which ones are even possible in the JVM. Label all (or none) of the ones that are “type safe.”

    LOL of course the android in c# is going out run Dalvik. CLR does not demand all operations be typed and all storage to be typed. So .net can be faster because it has to perform less checks.

    No, it’s because the ex-Ximian guys have had ten years’ experience and got it right. They’ve got the figures to prove it.

    What have you got, apart from bottomless ignorance and empty assertions?

  26. Clarence Moon says:

    An interesting philosophy, Mr. King, but you misstate the point. It is not better simply due to a bunch of people using it, but rather because people who have a great dependence on Photoshop have stayed with it, eschewing use of Gimp, for a long period of time. If Gimp had any validity, it surely would have come to the fore years ago. As it is, it is a mere curiosity, known only to a few hard-core FLOSSers. For the casual user, I would wager that Paint Shop Pro has orders of magnitudes more followers than Gimp.

  27. Adam King says:

    Well done brother Pogson. Your sermans are truely inspiring.

    @Clarence Moon
    Winbreds always trot out this argument as if photoshit was somehow “better” than the GIMP just because a bunch of people can use it. Frankly I don’t care what a bunch of mindless drones who eat whatever lies they’re fed without question think. They will flock to our banner in the end.

  28. Brillo says:

    The complex is CLR to JVM due to CLR striping type information.

    As I have already pointed out it is necessary for CIL to retain or else reflection simply won’t work.

    This is regardless of what your delusion has to say to you.

    C# is the complier only. Java for JVMs and Dalvik is complier and bytecode processing engine.

    I am sorry, but it doesn’t seem to me that even IBM agrees with you on this one as far as generics are concerned:

    http://www.ibm.com/developerworks/java/library/j-jtp01255/index.html

    “Generic types (or generics) bear a superficial resemblance to templates in C++, both in their syntax and in their expected use cases (such as container classes). But the similarity is only skin-deep — generics in the Java language are implemented almost entirely in the compiler, which performs type checking and type inference, and then generates ordinary, non-generic bytecodes.”

    This is different to the C# approach that a separate class (i.e. type) is generated each time a generic is called during declaration.

    Let’s face it, you are clearly wrong and uninformed on the subject matter, and you insist on fighting this pointless war of words despite it’s painfully obvious that the people you are arguing with are far more experienced than you in both languages. Rather than continuing to waste your critics’ time on same nonsense, why not just be honest for once and acknowledging that you have no idea what you are talking about?

    Linux has a very stable user-space ABIs. It just has very little tolerance for those who don’t use it as documented.

    A basic Linux stack (excluding Android, which is a completely different beast in itself) has the following three components:

    1) The Linux kernel
    2) libc
    3) X

    Setting aside the kernel, you still have libc, which can be of any variant, and X, which can be of any version, to worry about. Now crack open a math text book and figure out how many combinations of these things an ISV has to worry about.

    The problem is here is pretty much obvious and self-explanatory.

    So who fault is this. The documentation tells you to use memmove.

    Let’s face it – there is no reason whatsoever to make memcpy() and memmove() two separate functions. SunOS has mapped the two functions to the same code for like eternity. Even Linus Torvalds complains that the move by the glibc developers to change the behavior of memcpy is pointless:

    https://bugzilla.redhat.com/show_bug.cgi?id=638477#c38

    Of course, all this is just a story aside to the main point here…

    Yes the old library cannot be used but all the old programs can use the new library as as long as all this programs obeyed that libraries document ABI they will work.

    Let me repeat this for you once more:

    There is no reason for an ISV to worry about packaging third-party libraries. You either integrate the functions into your API, or you give them the necessary development kits for your distribution and integrate them properly into the development environment. This is exactly what MS does and ISVs love it because it saves them time and thus money.

    Stop arguing over the obvious – it’s tiresome and just unproductive.

    The applications that depend on that X11 issue you pointed to still work you just change in the new library.

    libxinerama is part of the X stack, and you are supposed to link against it as opposed to include it in your software. What that email points out is not just an ABI problem like memcpy() in glibc but overall instability of the API provided by that library. It’s pretty obvious that you are just trying to arw-wave your way out of a subject matter you don’t actually understand, but what’s new here anyway?

    Glibc only other breakages of applications have been applications using the glibc has been in a undocumented and even a non recommend usage way.

    Let me repeat this once for you:

    There is no benefit for that particular change, and there is no reason for ISVs to expect that change. This is not to mention that historically no distributions have offered simple and unified way for development (reads: development kits), and that means they need to waste time stitching together their own solutions (reads: integrating third-party libraries into their software) and resolving issues resulting from the underlying stack provided by the OS breaking it unexpectedly.

  29. Clarence Moon says:

    Nonsense.

    Well, the proof of the pudding, as they say. People who work with graphics items for a living use PhotoShop just about universally, along with some other applications. If it warms your heart, I think they also pretty much use it on Apple computers.

    Also, it doesn’t take many of their hours to swamp out the $699 or more that their company might be paying Adobe and the others for that software.

    It is fairly revealing that you admit a) you do not know how to use Photoshop effectively yourself and b) however it is that you use Gimp is not identical to using Photoshop. If it is so difficult for you to learn how to use Photoshop consider that those who do know how are not likely to want to repeat their learning curve with Gimp, no matter how much could be saved with initial licenses.

  30. TM wrote, “This may surprise you, but the cost of Photoshop is considerably lower than the cost of my time spent trying to get certain features of GIMP running.”

    Nonsense. There is no feature of GIMP that takes more than a few minutes to figure out and PS costs $699 up to $2600 depending on feature-set. It costs time to figure out all PS’s bloat as well. The last time I used PS, my task was to reformat a bunch of photos. I gave up trying to find the feature in the bloat and used ImageMagick instead. A line of typing did the whole job and it only took a minute or two to figure out what to type.

  31. oiaohm says:

    DrLoser
    “(and it’s easier from the CLR to the JVM, because the metadata is richer)”
    This is a lie because reality CLR to JVM cannot be done without running data-flow analysis. Because required information is missing.

    You can covert JVM to CLR without needing any middle processing steps because JVM has extra information. The simpler conversion of bytecodes is JVM to CLR. The complex is CLR to JVM due to CLR striping type information.

    DrLoser
    “the necessary tests to ensure that the bytecode is type-safe are done by the compiler. Absent bugs in either Java or C#, the bytecode will be type-safe.”

    The difference between the two languages is how type-safe is done. C# is the complier only. Java for JVMs and Dalvik is complier and bytecode processing engine.

    Reason JVM presumes the applications you are processing are possibly hostile and that someone will intentionally try to cause a type miss match to cause a bug. JVMs and Dalvik are the only bytecode engine that does type checking at bytecode. Everything else that uses a bytecode trust that the bytecode is typed correctly and that the complier did it.

    DrLoser
    “whereas this is explicitly declared in the CLR variable definition.”
    This is where people make a mistake. CLR stops at the outside of functions with the information. Sometimes even less. Why because it operates in the presume that everything inside is OK because the compliers said it was ok. You can strip these variable definitions down to the bare bone and the .net runtime still will accept it. Makes de-complier process harder it also makes bugs more possible.

    JVM and Dalvik has it in the bytecode following the variables inside functions. So you go to allocate a integer it checks that the storage is type integer if not fail. CLR can stuff up that if you trying to allocate integer storage to a string storage it might just happen if the storage is still not allocated.

    Even inside Dalvik it is maintains this storage must be typed. You cannot allocate to untyped storage. This is type cast operation not just type-safe.

    LOL of course the android in c# is going out run Dalvik. CLR does not demand all operations be typed and all storage to be typed. So .net can be faster because it has to perform less checks.

    Dalvik and JVMs are the only bytecode engines that demand type-safe at byte-code that is enforced by the JIT engines. There is overhead but a damaged binary is more likely to stop where it is damaged not keep on running.

    This is a classic case of speed vs secuirty. The c-sharp copy of android is less secure.

    Brillo
    https://bugzilla.redhat.com/show_bug.cgi?id=638477
    Go read this bug again. Adobe was using a mcmcpy
    Function description
    “The memcpy() function copies n bytes from memory area src to memory area dest. The memory areas should not overlap. Use memmove(3) if the memory areas do overlap.”
    Ok did memory areas overlap yes. Was Adobe using a undocumented feature yes. Did there program play up because they used an undocumented feature yes.

    So who fault is this. The documentation tells you to use memmove. Since its not a documented feature is not part of the ABI. Programs break on windows as well for using undocumented features of the ABI. Linux does not magically protect coders from this. Really should Linux protect coders from this. I really think not.

    Is there a tool under linux that would have told adobe that they had made this mistake. Yes there is it call valgrind. This also would have helped adobe avoid having as many memory leaks in flash.

    Brillo
    http://lists.freedesktop.org/archives/xorg/2004-February/000014.html
    The applications that depend on that X11 issue you pointed to still work you just change in the new library. The library is ABI compatible with the prior library. Yes the old library cannot be used but all the old programs can use the new library as as long as all this programs obeyed that libraries document ABI they will work. The result was not one program failed to work with the new library. So you are pointing to a no issue.

    Brillo Linux has a very stable user-space ABIs. It just has very little tolerance for those who don’t use it as documented. Adobe has a very bad track record of 1 not using libraries as documented and 2 not using the quality control tools like valgrind to detect cases when you have done that. So wait for their code to break. Adobe Flash brakes on Linux not one in fact traced to a single open source library breaking documents ABI. Breaking the undocumented and recommend not use way was broken.

    In the past 20 odd years of Linux there are only 3 cases of a documented ABI being broken. In each of those 3 case the ABI even at risk of security flaws was reinstated. In the same in in Windows ABI there have been 400 recorded cases. Windows ABI is smaller.

    Stability of ABI is not a valid argument against Linux. It one hell of a good argument against Windows. Not being able to find the Linux stable ABI because is got a lot of crud around it is a valid claim.

    There are a lot of libraries that are documented in the FOSS world that in there documentation there is a note we can change our ABI at any time. This is where the big problems come in. Person sees documentation think is a documented stable ABI and uses it and everything goes wrong.

    glibc all bar one case where a complete feature was removed in the last 20 years(mail directory support that was security flawed that had to be removed) there has been no true ABI breakage. Glibc only other breakages of applications have been applications using the glibc has been in a undocumented and even a non recommend usage way. Yes its like crossing a motorway while traffic is flowing you might get away with it if you keep on doing it one day you will get mowed down. Why is it important to follow the documentation. The testsuite of glibc only tests the ABI as documented same with many other libraries.

    Using windows abi to documentation you still might get mowed down.

  32. It should still be no contest, though. Linux is free! OEMs all know about it. It would be absolutely ridiculous to think they didn’t investigate Linux desktop alternatives considering they have to PAY for OEM licenses before they can pass that along to the customer.

    It doesn’t matter how many mythical “hookers and blow” a software company throws at a hardware company; If your free alternative is as good, or better, they’ll use it because it saves them money. So the fact that they DIDN’T is telling. Possibly something to do with support costs being considerably higher.

    This may surprise you, but the cost of Photoshop is considerably lower than the cost of my time spent trying to get certain features of GIMP running.

  33. Clarence Moon wrote, “There is no gun to the head here”.

    Hmmm… Reality is different.

    Prohibited Conduct in the “final agreement” with US DOJ v M$:
    “Microsoft shall not retaliate against an OEM by altering Microsoft’s commercial relations with that OEM, or by withholding newly introduced forms of non-monetary Consideration (including but not limited to new versions of existing forms of non-monetary Consideration) from that OEM, because it is known to Microsoft that the OEM is or is contemplating:
    -developing, distributing, promoting, using, selling, or licensing any software that competes with Microsoft Platform Software or any product or service that distributes or promotes any Non-Microsoft Middleware;
    -shipping a Personal Computer that (a) includes both a Windows Operating System Product and a non-Microsoft Operating System, or (b) will boot with more than one Operating System; or
    -exercising any of the options or alternatives provided for under this Final Judgment.”

    For decades, M$ conducted itself in those manners. Now, the Stockholm Syndrome has set in and some OEMs may well have felt that M$ was their friend. Friends don’t do those kinds of things. Perhaps Clarence is a victim here, too.

  34. kozmcrae says:

    Clarence Moon wrote:

    “Buy a Windows computer and the retailer, OEM, and Microsoft itself will hold your hand and get you going.”

    Yes they will. You can bring your Microsoft PC back to Best Buy as often as you need to and the geek squad will clean out all the malware and untangle your registry.

    Or, you can do like a lot of people do and just buy a new computer. It’s a great racket for Microsoft and Best Buy but its days are numbered.

  35. DrLoser says:

    One quick technical point, Oiaohm.

    You have to add metadata about types when you go from MSIL to JVM. Because particular information about type of objects has been stripped out. You get to drop metadata about types when you go from JVM to MSIL because it simply don’t give a stuff about type safety.

    No you don’t. You have to transform metadata about types (and it’s easier from the CLR to the JVM, because the metadata is richer). But, in either direction, you have to transform it.

    For example, in the JVM, all primitive types are expressed in the same 32-bit “register” (which is a bit of a pain for 64-bit information, btw. And for all I know, it’s been updated recently. I welcome correction).

    The necessary conclusion from this (because no language designers are stupid, with the possible exception of PHP) is that a lot of JVM bytecodes have the relevant data type embedded in them, whereas this is explicitly declared in the CLR variable definition. It doesn’t really matter either way: it’s actually just a detail of how you carry type information between the Java/.Net compiler and the runtime bytecode interpreter.

    But in either case — note that I am not at all criticising Java here — the necessary tests to ensure that the bytecode is type-safe are done by the compiler. Absent bugs in either Java or C#, the bytecode will be type-safe.

    Please note that this even applies to Java generics. Java generics are nothing more than syntactic sugar. This has a predictably catastrophic effect on performance and JITTing, but the compiler has already dealt with type safety. It has essentially done a macro transform of the original (necessarily verbose) Java code.

    Here’s another interesting link on the comparison (brought to you via a Linux-based company that hates Novell).

    Possibly you, too, have further educational material to offer. None of that two-year-old worthless XML guff, please.

  36. Clarence Moon says:

    You confuse cause and effect here, Mr. Pogson. If OEMs felt compelled to offer Windows on Microsoft’s terms it was because they were selling Windows Computers and that was their free choice. By way of proof, I can only say that, even today, there are companies that sell Linux computers, eschewing Windows entirely, and there is no sort of retribution from Microsoft. There are other companies, Dell for example, that sell mostly Windows computers but have offered Linux versions off and on for more than a decade.

    You can complain that Microsoft toots their own horn and tries to make deals to cement their relationships with major OEM customers who can benefit from those deals. You may not be aware of the massive amount of deals offered major corporations who are willing to commit to site license coverage on an annual fee basis, thus saving large sums compared to purchasing Windows or MS Office or other Microsoft products via distribution chains. All of that is done to promote Microsoft products exclusively to the exclusion of any others. That is what they are in business to do, after all.

    There is no gun to the head here, though, Mr. Pogson. Microsoft offers an attractive deal and Microsoft’s competitors offer an inferior option, inferior at least for the purposes of the customer’s business.

    Certainly an in the know customer can go around Robin Hood’s barn and substitute some strain of Linux and a variety of open source/freeware applications for the “real” thing, but what do they save as a result of some intensive study and effort? A handful of dollars that goes nowhere far enough to compensate for the labor involved.

    Buy a Windows computer and the retailer, OEM, and Microsoft itself will hold your hand and get you going. Buy a Linux computer and you are largely on your own. You have to factor in things outside of just bits and bytes when you make a product decision.

  37. Brillo says:

    That’s sliding over some sharp details like exclusive dealing with OEMs

    That reminds me:

    I said every time you cited something from Groklaw, I’d post a link to IBM and the Holocaust.

    See who’s supporting Linux 100%, eh?

  38. Clarence Moon wrote, “we have to go out and convince the world that we are the best by showing them comparisons of our products”.

    That’s sliding over some sharp details like exclusive dealing with OEMs, spreading FUD far and wide, funding SCOG v World, etc. If all M$ did was advertise, I would have no squabble with them. They do not follow the rules of a fair market. If their products were truly superior, why would all the dirty tricks be necessary? Would they not be a waste of funds? Instead they use every possible dirty trick to pressure the world into using their stuff.

    It was the economic equivalent of a “gun to the head” to tell an OEM in the 1990s that they had to ship that other OS with a ton of restrictions or not to ship it at all. The OEMs danced to the tune M$ called. So did the retailers because that’s all they could find to sell. So did the “ISV”s because if you wanted to sell software they were forced to write for that other OS. That’s a lot more than advertising.

  39. Clarence Moon says:

    The worst kind where the slave-master enlists members of the group to enslave the rest

    Do you ever wonder why people are often taken aback at your ranting, Mr. Pogson? I show where Microsoft evangelists tell themselves that “we have to go out and convince the world that we are the best by showing them comparisons of our products” and you liken that to the Gestapo holding a gun to the heads of Polish Jews. That is not an answer, that is a collapse of reason.

    You are far too sensible to indulge in such bizarre references. Moderation will always trump fanaticism.

  40. Brillo says:

    Because particular information about type of objects has been stripped out.

    No. C# supports reflection, and this makes it necessary for CIL to preserve type-relation information otherwise reflection simply won’t work.

    http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx

    The problem here is generics data is in bytecode.

    Do you understand what “generics” are?

    http://msdn.microsoft.com/en-us/library/512aeb7t(v=vs.80).aspx

    http://docs.oracle.com/javase/tutorial/java/generics/types.html

    To refer to my previous link, a class with generics in C# has no type until it is declared. On the other hand, generics in Java are defaulted to java.lang.Object unless you substitute them with the subclasses of java.lang.Object (reads: almost everything in Java API). This is why it’s perfectly acceptable to write something like:

    java.util.ArrayList list = new java.util.ArrayList();

    without the compiler barking at you. Anything beyond the compiler in C# is handled by CIL metadata, which by necessity contain type information.

    And, no, it doesn’t appear to me that JDK 7 has gone beyond playing around with java.lang.Object and polymorphism.

  41. Brillo says:

    This list is almost never. Only place libc you get screwed over is in fact android. kernel abi to userspace is stable only issue if you want a kernel mode driver. So if you program states Linux kernel X version or latter you are fine.

    If by “almost never” you mean except when a function gets spontaneously changed in glibc:

    https://bugzilla.redhat.com/show_bug.cgi?id=638477

    Or when a distro suddenly packages a newer version of X:

    http://lists.freedesktop.org/archives/xorg/2004-February/000013.html

    Please, stop wasting my time with your imaginary knowledge in the subject matter.

    Using libraries like boost and not shipping them with you program.

    Irrelevant. Needing to package any third-party library in your software is a headache in itself. Needing to package a sheer amount of libraries because the only things you know are definitely there are the bare basic POSIX calls is even bigger a headache. Not knowing that if any of these libraries will break at any time because of the instability of the underlying stack… Well, you get the idea.

    Under Linux due to some distributions being stupid the developer uses distribution provided version.

    This is where you miss the point. This whole issue is not about ABI, but API. You are not making things better for developer by making them package their own libraries. Instead, you either give them the development kits and integrate them to the development environment or you just build the functions directly into the API of the OS. Time is money, and this is exactly the basic mechanics of business that both you and PR don’t understand.

    Same with third party using undocumented functions in windows

    Irrelevant. It’s not MS fault that some ISVs insist on using undocumented functions for their software, and I do believe that the argument from PR is that MS is somehow providing a rich API to “entice” ISVs to develop on Windows.

    Come back to Earth first before replying to my comments.

  42. oiaohm says:

    DrLoser “.Net (MSIL) to JVM, you would necessarily be losing metadata. Which is fine.”

    You have to add metadata about types when you go from MSIL to JVM. Because particular information about type of objects has been stripped out. You get to drop metadata about types when you go from JVM to MSIL because it simply don’t give a stuff about type safety.

    The problem here is at MSIL everything is basically generic everything. No type safety at all.

    If java did not have types in it bytecode you would not have to run the data-flow analysis when convert from MSIL to JVM. Yes it simpler to convert from JVM to MSIL due to MSIL being the security weaker one.

    type cast come from what I called them coding C++. Also comes from using ccured and cyclone

    DrLoser
    “One not very interesting thing here. Java, by general consensus, botched generics badly. The result is that all generic types in Java are upcast to the base class, which is “Object.” In practice, this doesn’t necessarily matter.”

    The problem here is generics data is in bytecode. You have a type compare and a class compare in java. Both can give wildly different results. One can say two object the same because they are using the same class one will say they are different because they are different generic types. Yes it is botched but not how must people claim. You come aware when you do conversions from .net to java and back.

    DrLoser
    “But it doesn’t matter whether it’s Java or C# or PHP or Python or even Perl: there’s no strong typing involved.”
    This is a false statement. To implement operator require altering the bytecode in JVM so it would accept doing a generic operation without a hack. Its one of the bytecode feature that make a Java 7 jar not run on a Java 6 jar or before.

    “Java 5 introduced generics” is a little bit of a joke. was really lets just connect more type data and do more type checking resulting in needing even more code. Lets forget the most important thing about generics a generic operator.

    So really Java5 and 6 is generic in name and look but very strict type checking at the bytecode processing.

    Java 4 and before Java had nothing call generics it was perfectly type match.

    DrLoser for java support .net runtime does implement some type checking. Its not everywhere. MSIL bytecode is not type safe like JVM is. All the problems with generics under JVM comes from the fact Java bytecode was design to avoid generics. If you have type in Java that is a special type of string and you try giving that to an normal string it will error.

    There is a mistake on the Wikipedia and other sites by the way. They do a class compare since that return true Java bytecode dropped the generics information. Reality use the right look command and it still has the correct information as coded. The JVM is using it. This is how come JVM will fail with miss matched JAR files more often that some people think is a problem. .net should fail more it does not have the information to know it should fail.

    But to be really annoy the default Java language does not define how to get the generics information back from inside the program in a programmer friendly way. Third party to the rescue https://github.com/jhalterman/typetools . So at runtime you can look up all the generics you set at build time. And if the bytecode does not have generics information the JVM will not run it because its is really checking the generics.

    Not everything about Java is sane. Looking up the generic type of a class is a true pain in the but in Java. Just because it is a pain in the but a lot of people mistakenly believe its not recorded in the JVM bytecode. Don’t put in the JVM will not run the bytecode that simple. Type data or do not run Java 5 or newer because the JVM will not play ball.

    MSIL its not there at all this is why you have to generate it when migrating.

    Basically java comes nicer with Java 7 adding but nicer still would be adding a generic type look up to the java language instead of keeping it a JVM secret.

    Some of the non java languages for JVM’s implement the look up.

    Security wise JVM bytecode is major-ally better than MSIL. The common language people use on top suxs because it lacks some highly useful defines how to get highly useful information like what type is that.

    Also people are not very observant you know how you have multi of the same functions accepting different types in class. That works yes the tell me the type class works as well even on classes that have not had a value set yet works in java. MSIL this gets interesting because the generics are gone. The JVM has to have a way of find the generic set information out otherwise it could not choose between the different functions in a class correctly based on the generic set. This is clue that could has recorded it is in the bytecode. Lot of digging latter you find out it is but in a hard to access location.

  43. oiaohm says:

    Brillo

    “I am willing to wager that Pogson will just believe in all this nonsense without any fact-checking. Still:

    http://stackoverflow.com/questions/1914121/does-net-typecast-when-an-object-is-used-in-collection-using-generics
    This is talking about the complier not the byte-code it should check it but its not bug free.

    Becomes very clear when you run this beast over it http://xmlvm.org/overview/

    Brillo because I hoping Phenom would respond over that C# one not there. But you are the idiot that walked into that one. xmlvm takes the CLR/CLI of net and turns it it JVM. In the process of conversion you perform data-flow analysis. This finds lot of .net complier and link errors in produced bytecode.

    Basically C# its typecast the produced bytecode is not in .net. Just to be fun the .net compliers when linking many files into a single binary can in fact fail to check the typing correctly. Leaving nice hidden random bugs in .net programs. That are really fast to find if you run xmlvm over it.

    Having the right tools is key. Anyone who knows .net issue will have a data-flow analysis program of some form to check the final binaries to make sure you have not linked a old cached version of something in. So the typing is correct so you don’t have random bugs by something you can prevent.

    Brillo
    “List myList = new List(); //<– big mama of a compilation error"
    This is theory. In the CLR bytecode of .net that is valid code just the C# complier is stopping you from building it. So the program is not going to crash at runtime because of that if the complier did not check.
    "List lststrs= new List();”
    This is what it should be right.
    You run data-flow analysis you find in another part of the program
    “List lststrs= new List();”
    With the program running between the two.

    This is the kind of complier error I am talking about. Now you have string operations being performed on int32 you int32 operations being performed on string. At this point you are wonder what in heck is wrong with your program.

    Normal case is build cache has ruined you .net day. So the current source code does not show “List lststrs= new List();” So you can read the source code as much as you like the error is not in the source its in the produced bytecode and the caching of the complier. Since it works unless the operation that cause it to go wrong happens something like this can pass final testing if you are a group not using data-flow analysis program on .net output binaries.

    Something like that with runtime typing jvm does would fail with a runtime error. Jvm you don’t have to remember todo an extra step. .net runtime can and does let it slide so you must do the extra step of data-flow analysis to make sure you have what you think you have.

    I am talking about where you code appears fine and the compiler builds it anyhow. One of other areas of trap here is third party libraries. You update a third party library you don’t rebuild a section of your .net program and now you have a type miss match that runs. Ok hopefully it will crash. It is possible that it will not crash and just do something you are complete not expecting with .net.

    Really .net is as bad as C at runtime.

    Brillo basically those libcruft-0.21.3, libjunk-0.34.1 apply to .net for ruining your day.

    Brillo
    “X, kernel and libc (which you have no way to predict) won’t screw you over.”
    This list is almost never. Only place libc you get screwed over is in fact android. kernel abi to userspace is stable only issue if you want a kernel mode driver. So if you program states Linux kernel X version or latter you are fine.

    X11 its not X by the way. Video card drivers screw you over(same on windows in fact). Not X11 that much. Unless of course you are using undocumented functions. Then pain of death is your fault.

    Most common cause of programs not being able to migrate between distributions.

    1) Using libraries like boost and not shipping them with you program. What is the problem they are not ABI stable libraries even under windows. Under windows person using them ships them with there program. Under Linux due to some distributions being stupid the developer uses distribution provided version. So when the distribution updates all its boost using programs the third party developer is screwed.

    Now it a lot ways we could as a community make it simpler for third party developers. Create a tool that scans there binary and reports what libraries they are using that are not ABI stable. Yes a single version number change on boost can break compatibility.

    This would be part of providing packaging for ISV’s that works. Linux Standard Base binaries loader is like your windows binaries. You can place the ABI unstable library in a directory to be used by your own programs.

    Yes 1 problem causes almost all the case of third party programs failing to be cross distribution.

    Price is going to be size of your program. Linux distribution versions of programs are lot smaller than your windows relations because they don’t have to ship duplicate libraries and can depend on package dependences to keep that sorted out.

    Yes its the problem of a third party they have to be aware the distribution packaging is off limits unless the library is ABI stable.

    Same with third party using undocumented functions in windows and having there programs break. Basically Linux has more that you would class as undocumented except its documented and marked ABI unstable. Using the unstable your program still runs this is the problem. A ISV environment exposing only ABI stable libraries exists.

  44. DrLoser says:

    I beg Robert’s leave to comment on this:

    .Net is not without its problems. There is a catch with CLR most people are not aware. CLR bytecode is not typecast. This can lead to some nasty exploits that fail when on a JVM. Yes subtle coding errors by complier in .net are exposed when you covert it.

    I merely wish to interject, as it were, a technical explanation of “type.”

    What Oiaohm describes as “typecasts” are, in fact, antithetical to type safety. (Many people make this mistake when looking technical stuff up on Google.)

    A “typecast” in C is nothing more or less than a “reinterpret-cast” in C++, which is generally frowned upon. It’s so opposite to type safety that I would seriously not recommend using it in any environment whatsoever.

    However, assuming that Oiaohm meant “type safety,” we have the makings of an interesting discussion. As an aside, I will point everybody at Lambda the Ultimate, which is a fairly comprehensive authority on the subject. Sadly, not as authoritative as Wikipedia, but authoritative nonetheless.

    One not very interesting thing here. Java, by general consensus, botched generics badly. The result is that all generic types in Java are upcast to the base class, which is “Object.” In practice, this doesn’t necessarily matter.

    Equally uninterestingly, C++ takes a very strict view on this, which is where reinterpret-cast comes in.

    C# occupies a middle ground, where typecastings in generics offer some sort of a contract, but you have to understand what that contract is…

    … which is where the interesting bit comes in, so here’s the interesting bit:

    None of this has anything to do with the underlying bytecode.

    None whatsoever. Just as with Assembler, bytecode is bytecode. It has almost no type information at all (apart from an indication as to object size and another one as to whether or not the garbage collector is involved).

    But it doesn’t matter whether it’s Java or C# or PHP or Python or even Perl: there’s no strong typing involved.

    What you’re left with, interestingly enough, is metadata. I’m not sure about Perl and Python and PHP (well, tbh I’m pretty sure about PHP), but the MSIL language is far richer in metadata than is JVM bytecode (applying, obviously, to either the Sun reference model or to the Dalvik alternative, since pari passu they are forced to be the same).

    Well, just thought I’d interject.

    The end deduction from all this, of course, is that Oiaohm is looking down the wrong end of the telescope. It doesn’t matter whether you can, theoretically, transform .Net bytecode to JVM bytecode via a bridge between the two respective ASTs. To go from .Net (MSIL) to JVM, you would necessarily be losing metadata. Which is fine.

    As long as you admit that you are doing it.

    Oh, and “typecast?”

    An interesting choice of term.

  45. Brillo says:

    Phenom would help if people like you read the wikipedia for basic information.

    Did you even read your own link? Do you see C# there?

    If you see it, go find a doctor.

    Development tools to build the applications is there for Linux. Its simple packaging to ship the applications is where there is a weakness.

    Yeah, its a simple packaging of libcruft-0.21.3, libjunk-0.34.1 and so forth and hoping that the target combination of X, kernel and libc (which you have no way to predict) won’t screw you over.

    Easy peasy.

    Yes subtle coding errors by complier in .net are exposed when you covert it. Because programs that should not work build with the MS C# complier.

    I am willing to wager that Pogson will just believe in all this nonsense without any fact-checking. Still:

    http://stackoverflow.com/questions/1914121/does-net-typecast-when-an-object-is-used-in-collection-using-generics

  46. iLia says:

    Now, M$, inspired by Apple’s success in making walled gardens lucrative

    Ok, when Google does the same it is just fine, but when Apple and Microsoft do the same they try to monopolize and enslave. Double standards?

    Phenom Kdevelop, Qt Creator and QML exist.

    By the way Nokia fires its QT developers.

    And please don’t mention Glade, or I will start some mass-murder in the nearest cinema.

    GNU/Linux offers more for developers, more tools, more libraries, more performance, more freedom than M$ could ever hope to offer.

    A lot of half-baked crapware written by armatures.

    .Net is at least homogeneous and written by profs. And there is a lot of third party libraries for it.

    more libraries

    KDE, Gnome pick one and the users of the other will never install your software. And don’t forget about sound on Linux. Or it’s absence.

    Personally, I like VIM and FreePascal. Both of these offer me more than I need for developing software.

    Personally, I like .Net. It is huge, it is well documented, C# just perfect and there are a lot of other languages for .Net.

    Running on GNU/Linux with its multi-user/multi-tasking capabilities these tools and the resulting applications sing to me.

    Too much LSD, Mr.Pogson?

    And Windows actually also has multi-tasking capabilities.

    Multi-user? How often do you have several users working with your computer simultaneously?

    And why Ubuntu closes all my running programs when I try to “Log Out”? Why it doesn’t keep them like Windows XP?

  47. Phenom says:

    Pogson, just an example of something you won’t find in VIM, or FreePascal, or even Eclipse:
    http://msdn.microsoft.com/en-us/library/ms164746.aspx

    You can’t even believe how helpful is this in multithreaded apps, which utilize the many cores we have these days.

    As for MS not helping ISVs… What about a help like MAPS for ISV, which costs $420 / year and gives an ISV software worth tens of thousands of dollars? Or what about BizSpark?

  48. oiaohm says:

    Phenom Kdevelop, Qt Creator and QML exist.

    Eclipse netbeans and many other java solutions exist.

    If you like C# syntax but not its performance issues you have Vala.

    Phenom really asking for just give us Visual Studio is being extremely vague. There are a lot of IDE’s in that class.

    Also java is a lot more like .net than many give it credit. http://en.wikipedia.org/wiki/List_of_JVM_languages Phenom would help if people like you read the wikipedia for basic information. To come aware that a JVM and CLR(the back end of .net) don’t really make that much difference. It is possible to translate CLR(.net binary) to a JVM binary. Due to the legal status of Java been known you are more likely to find JVM pre-installed on Linux platforms.

    Lot of people think writing for a JVM requires coding in Java. Not the case. You can code in C# produce a CLR and convert that to a Java class if you wish. So to a well setup developer .net and java are mostly interchangeable.

    Phenom .Net is not without its problems. There is a catch with CLR most people are not aware. CLR bytecode is not typecast. This can lead to some nasty exploits that fail when on a JVM. Yes subtle coding errors by complier in .net are exposed when you covert it. Because programs that should not work build with the MS C# complier. Yes the conversion process you are performing a type of variable usage check. Result more secure .net code after the conversion.

    Eclipse I don’t use because it a pain in ass. Netbeans for java code is less buggy.

    Phenom really you are talking about stuff that is not issues really. There is a more important issue the Fragmentation one.

    Development tools to build the applications is there for Linux. Its simple packaging to ship the applications is where there is a weakness.

    Of course there are some people who if it not visual studio they will not code. Heck there are some people no emacs they will not code as well.

    Phenom basically drop the more tools please one. We all know that is bogus. Development tools Linux has enough of those. Ok maybe there needs to be a guide to what development options you have on Linux with there pro and cons.

    Like freepascal yes it pascal but you still can make java programs and android programs. So those old legacy code bases can be forward converted.

  49. Clarence wrote, “What sort of “slavery” is that,”?

    The worst kind where the slave-master enlists members of the group to enslave the rest.

  50. Clarence Moon says:

    Both of these offer me more than I need for developing software

    VIM and Pascal? If that is what FLOSS developers might choose, would open source free-style swimmers wear combat boots and only use one arm. After all, anything goes, right?

    Java was a great idea, but it didn’t evolve much beyond being a C++ sort of VB. C# was the improvement that really made things work. Cool! (if you get the pun)

  51. Clarence Moon says:

    From the preamble of the first document in your cite:

    “We can only convince, not compel. Those who adopt our standards do so as a rational decision to serve their own ends, whatever those may be. It is our job to ensure that those choosing an operating system are presented with an overwhelming abundance of evidence and reasoned argument in favor of our standards…”

    What sort of “slavery” is that, Mr. Pogson? You are far too over the top. Rather than whining about the cruelty of Microsoft, you FLOSSers should get out and evangelize effectively on your own. Maybe then you would see why your message constantly falls on deaf ears.

    Microsoft had a message that many were willing to hear and they invested their time and money to bring that message to those who wanted to hear it. The FLOSS bunch presentations consistently lack any of the sort of “reasoned argument” that serves Microsoft so well.

    M$ did not do any of that to aid ISVs but to aid M$.

    It is not such a one-sided affair, Mr. Pogson. The ISV prosper and Microsoft prospers as a result. It is what is always called “win-win” and you don’t seem to have much regard for that. Until you learn that lesson, you are doomed to miss out.

  52. Phenom wrote, “Pogson, when Linux offers developers something like “

    GNU/Linux offers more for developers, more tools, more libraries, more performance, more freedom than M$ could ever hope to offer. Personally, I like VIM and FreePascal. Both of these offer me more than I need for developing software. Running on GNU/Linux with its multi-user/multi-tasking capabilities these tools and the resulting applications sing to me.

  53. Phenom says:

    Pogson, when Linux offers developers something like .NET and Visual Studio IDE (no, Java and Eclipse do not count), then you may call developers again.

Leave a Reply