Windows Longhaul? Release not to be seen until 2008?

Discussions

News: Windows Longhaul? Release not to be seen until 2008?

  1. Gartner research VP Tom Bittman predicts "with Gartner's irritating probability-speak" that Longhorn may not ship until late 2006 to mid-2008 and beyond.

    The Register ponders the consequences of this: "Microsoft could be maiming its sales teams by sending them out without credible roadmaps, and talking up something it can't ship for years, just when Sun is starting to look dangerous on Microsoft's home turf, too.

    We think that if Microsoft can't nail Longhorn down absolutely to 2006 pretty soon, it's going to have to come up with some interim ideas to hold the fort."

    Gartner report:
    http://www.informationweek.com/story/showArticle.jhtml?articleID=16700197

    The Register article on the subject is here:
    http://www.theregister.co.uk/content/4/34500.html

    Threaded Messages (25)

  2. What about .net?
  3. Longhorn 2008?[ Go to top ]

    The moment that Microsoft converted all of its customers to subscription-based software assurance licenses, they lost most of their incentive to develop new product.

    It used to be that they had to come up with compelling new upgrades every two years, because the onus was on Microsoft to convince their clients to upgrade.

    Now, they get their money whether they improve their products or not, and they have years to tinker around with a new 'content delivery platform' in Longhorn that will allow them to expand to other markets.

    There is a relevant lesson here for us, as Sun is also in the process of migrating to a subscription-based software model.
  4. Sun Subscription Model[ Go to top ]

    Sun's subscription model is one of the models available to its customers. It is not the only model. Sun releases product updates on a quarterly basis and features are rolled in at those release points. Finally, the Java Enterprise System and Java Desktop System are based on open standards, so customers are not locked in.

    The lesson isn't the subscription model IMHO as the subscription model, if implemented correctly, is appropriate for many but not all customers. The lesson is in the use of, building to and deploying on proprietary APIs.

    John Clingan
    Sun Microsystems
  5. Standards[ Go to top ]

    The lesson is in the use of, building to and deploying on proprietary APIs.


    What is the standard in Java Desktop system ?

    Linux = ISO ????, ECMA ????

    Java = ISO ????, ECMA ????
  6. Standards[ Go to top ]

    Java = JCP Standard

    JCP = Umbrella organisation of the industry, for the industry, by the industry.
  7. Standards[ Go to top ]

    Yup.
  8. You are missing the point[ Go to top ]

    Emphasis on the word "industry" as opposed to one vendor.
  9. Standards[ Go to top ]

    Oh god, here we go again.
  10. JVM in .Net?[ Go to top ]

    One thing I read about longhorn is that the win32 api will no longer be the native api and any win32 apps will run in a .net managed process. If this is true, will Sun need to release a version of the java virtual machine as a .net assembly for optimal performance?
  11. New generation of applications use a Managed Win API ("WinFX") -
    sort of like a true Java OS that never shipped.

    Old apps (win32) stay the same.


    You can read up on it -
    http://longhorn.msdn.microsoft.com/
  12. is this slashdot?[ Go to top ]

    or is it just a slow news day?
  13. Who needs longhorn we have linux[ Go to top ]

    I know why longhorng is taking time cause M$ cannot copy it from some one else's code
    like they did with c# copy cat of java.

    But who needs longhorn when we have linux. Java and Linux compliments each other.
  14. Money for old Rope[ Go to top ]

    How many people are going to get burned having signed Software Assurance and realising that they are going to get squat for their money. A three year guaranteed upgrade program where you get nothing! My guess is that MS will do a Win ME and release an XP+ stopgap to appear as if they are releasing new software when all they are doing is milking there install base.

    Jay
  15. No, seriously, what's Sun got to do with it? Other than having an anti-Microsoft troll at the helm -- which does more to shoot Sun in the foot than hurt Microsoft -- I just can't see Sun as a threat to anyone.

    Sun's main business is still selling overpriced, underperforming hardware. (Yes, even their Linux boxes, contrary to Sun's marketting BS, are a lot more expensive than if you configured the exact same Xeon system on Dell's site.) That some people still buy them, is pretty much a marketting miracle, but then MS has good marketting people too. Still, even that market is slowly drying out.

    Java itself is good, but Sun doesn't make any money directly out of Java.

    J2EE is a mixture of good and bad. The bad being that Sun's hype machine pushed a lot of projects to use a bunch of buzzwords that they didn't actually need. (E.g., let's be honest, about 90% of the projects who use EJB didn't actually need them, other than buzzword value.)

    We're talking probably tens of billions wasted per year because of that hype alone. _Increased_ development times, expensive consultants for snake oil products, app-server specs that change in the middle of a project, etc. That's what abusing EJB as the latest cool fashion (as opposed to being actually _needed_ after careful analysis) really brought this industry.

    Combined with the sorry state of the application servers (e.g., that buggy joke called WebSphere 5)... there are a lot of people who got burned on J2EE.

    Maybe an undeserved reputation, yes. But a reputation it's starting to get nevertheless. Or maybe not entirely undeserved. A bit more honesty in advertising could helped avoid that.

    Basically, dunno, the more I think about it, the more Sun looks like it's more of a danger to itself than to Microsoft.
  16. Bingo! Well said.
  17. A bit noisy in here ...[ Go to top ]

    Cristian,

    Several people believe that the Java Enterprise System poses a credible threat to Microsoft. I myself believe that it does. Let us look at software reviews or try the thing out. If there are problems, then we will see how they get resolved.

    Was there hype surrounding J2EE? Sure. I was excited because I didn't want to learn a new API for each application server I came across. Some of this hype was generated by developers too. Do you want to hurl insults at developers?

    I like EJB. I look at EJB as a nice way to get transactions using both synchronous and asynchronous invocation. Many experienced EJB developers have pointed to security as a nice benefit of EJB.

    By the way, some of the people who got burned on J2EE were those developers who were assigned to J2EE projects and couldn't get up to speed in time. So, why are you so angry?

    -jonnie
  18. Heh[ Go to top ]

    By the way, some of the people who got burned on J2EE were those developers who were assigned to J2EE projects and couldn't get up to speed in time. So, why are you so angry?

    I was wondering when would someone step in with the usual "if you're complaining, you're an incompetent." I must admit though that the phrasing above is very diplomatic, but is in the end the same insult. And still the same old issue of The Emperor's New Clothes. (Surely only idiots can't see the fine clothes our Emperor is wearing.)

    But let's not get into that flame-war. Why am I so angry?

    Well, want to come deploy this beast on WebSphere 5 for me? The whole application takes 4 hours to export off the test server. The GUI alone takes half an hour to deploy through the Admin Console. (Admittedly, that test system is "only" a two CPU Sun workstation with a gigabyte RAM;)

    Anyone from IBM want to exactly explain how does this improve my productivity and reduce the TCO, please? No, I'm serious. I want to know.

    Or here's a small sample of other issues, only off the top of my head, which we faced over the last year.

    - XA exceptions when using more than one Oracle database in the same transaction? Check. (Fixed in WS 5.0.1.) That caused the whole team to first scramble frantically to diagnose the issue for two weeks... then wait another 42 days for IBM to fix it.

    - Severe performance problems in the DataSource when using JAAS? Check. (Fix PQ79683.) More time lost, and more teams from several projects scrambling to find out why that promised land of scalable J2EE architectures... doesn't scale.

    - ClassCastExceptions due to an ORB bug on Solaris, when two session beans call each other? Check. More time lost diagnosing IBM bugs, and one huge administrative overhead to keep the application working in the meantime. (Unnamed fix from IBM, which basically made the server crash upon start-up. Obviously never actually tested on WebSphere.)

    - Exceptions being silently caught and replaced by other (completely wrong) exceptions? Check. E.g., what should have come as a ClassNotFoundException at deserializing, in WebSphere comes back as a NotSerializableException. Heck, yeah, that's got to improve our speed at diagnosing problems. (Not fixed.)

    - Wrong or misleading error messages in the tools? Check. E.g., the Tivoli Perfomance Viewer says that no server has the performance monitoring turned on, instead of saying that the password is wrong. (Not fixed.)

    - WebSphere 5.0.2 filling the logs with NumberFormatException lines when performance monitoring was enabled? Check. (Unnamed fix from IBM.)

    Etc, etc, etc. Seems to me like WAS 5 alone is enough reason to be angry.

    Plus, no, I'm not talking about the excitement of learning new stuff. (Which I do still have.)

    I'm talking about the wisdom to sometimes say "ok, this new stuff I've learned might be cool, but here and now it is not what we need." After all, just because you've learned to drive, doesn't mean you should outfit the server with a steering wheel and pedals.

    And about the honesty to recommend what the client really _needs_, not the buzzwords you wish to have on your resume. Which is what some of that hype from developpers is all about. As soon as some new buzzword is in vogue, everyone scrambles to get it on their resume. It doesn't matter if the client really needs it, or if it even makes sense for the current problem. All that matters is that at the next job interview you'll have another buzzword to show off.

    Which is just as dishonest as if a surgeon deliberately mis-diagnosed you, just so he can get a heart operation on his resume.
  19. Heh[ Go to top ]

    I agree 100% with you about the problems with WebSphere. However, I would not blame J2EE for your woes.

    It is true that one needs to do more research and spend more time learning about techniques, do's and don'ts, etc. But once you are past that learning curve, you have awesome power in your hands.

    Nothing is free. Great power comes with great responsibility. The choice is yours. Me, I would rather take the pains to delve deeper and tap the power rather than let a vendor make all my decisions for me.
  20. My point was more like the face a _client_ sees when dealing with J2EE. They usually don't know the technical details, and got sold on an app server and on some buzzwords by some marketroid.

    E.g., believe it or not, it was _not_ our choice to use WebSphere here, but a "strategic decision" of the client. It was either WebSphere 4, or WebSphere 5. Period. WebSphere 4 had no standard-conform way of using MDB, so here we are stranded in WAS 5 wonderland.

    But, either way, I'm talking not about what _we_ can do with EJBs. (At the very least, we were able to find all those WebSphere bugs.) I'm talking about what the client's PHB sees. E.g.:

    - higher costs. You mention that learning curve there. That's just what it means: more expensive people. In VB you can get just about any burger-flipper to string a program together in no time. (Maybe insecure and flawed, like anything done by unskilled people, but nevertheless it at least looks like what the client asked for.) With EJB you need people who are past that learning curve. They're more expensive.

    - much as WebSphere is not made by Sun, as I've said, the client tends not to see those details. What they see is more along the lines of "our EJB projects took longer. And those people only kept complaining about the tools, instead of delivering the damn program." I.e., it may not be Sun's fault, but it's shooting Sun in the foot anyway.

    Plus, there _are_ a bunch of disadvantages which _are_ inherent to the EJB specification. And which _do_ translate directly into increased development times.

    E.g., the need to serialize and de-serialize classes means both ends have to actually have all the class definitions. Which in turn prevents you from doing any good OO design. If a client program wants to sub-class a data object, as a proper OO design would require, they can't just pass it to the server as such. It can't be de-serialized on the server. You're effectively either back to the bad old days of C style structs (yes, a pure data object with only getters and setters is just a glorified struct), or you create redundant classes and write code to copy data from the server's objects to your own.

    E.g., the exact same need to serialize/deserialize creates a much too tight coupling between the server and the client. The tiniest change on one end (e.g., an extra helper method) can cause the other die horribly with a serial version UID mis-match. For a framework supposed to encourage loosely coupled components, it sure fails miserably at precisely that.

    E.g., it does increase complexity. By the time you've written all those homes, remotes, facade classes, and applied a few patterns for good measure, you've written 2 to 3 times more code. Code which will not only need to be written once, but it's actually more code to maintain too.

    Etc.

    Now there _are_ problems where the architecture has its advantages, and yes, they do outweigh the dis-advantages in that case.

    But the problem starts when that shameless hype gets it pushed into problems where it wasn't needed or even applicable to start with. There the advantages don't exist, or don't matter, but the dis-advantages remain. Same as with any other mis-applied technology, really.

    And in that case, in the long run the hype does IMHO more hurt than good. The client won't see it as "gee, I was a retard to demand all the possible buzzwords", and they won't understand that "EJB != J2EE" either. They'll see it simply as "gee, this J2EE stuff sure is more expensive." And from there it's just a small step to "oh no, I'm not doing that mistake yet again."
  21. Misguided Industry.[ Go to top ]

    Ever stopped to think what a mess IT industry really is? I too develop with Java and also .Net. If its my product I am doing, spending my money, I would pick M$ and .Net hands down! But... I work for money, and I don't make the decisions. I don't let the tools/products thing bother me, I try to play on anything that the client is willing to pay me for end of story. On the J2EE space, I like weblogic. You install the thing and it works, infact it dances a pretty nice step, I have had my headaches with Oracle App server, and lately Netscape (Arghhh.. what a product. It has to be worse than Websphere surely). Anyway, things can get expensive when the damn server doesn't work and you have to spend many precious days fighting it. I think .Net is cheapest and most productive, closely followed by Weblogic, and everyone else is in an entirely diffferent planet. Have you seen the latest Weblogic? Its so M$, thats right, it was writen by former M$ engineers so no surprise, and I have to hand it to those guys, they are brilliant true? Whats wrong with IT? Its driven by the wrong crowd, the big decisions are made by business people who don't have a crew about software, so the loudest mouth always gets the most points across, thats how you end up using the likes of Websphere. The best products are often overlooked, and the better developers often blown off. Thats all I got to say. Look at the recruiters, whats a recruiter to do when the don't know a thing about what they are recruiting for? Hire the guy with the most buzzwords on his resume, stupid but true. I have often felt rather stupid having to sprinkle 3 letter acronyms all over mine so that it can get picked, its an insult to onces intelligence, but that is the yard stick used, what can we do..
  22. Heh[ Go to top ]


    > Well, want to come deploy this beast on WebSphere 5 for me? The whole application takes 4 hours to export off the test server. The GUI alone takes half an hour to deploy through the Admin Console. (Admittedly, that test system is "only" a two CPU Sun workstation with a gigabyte RAM;)
    >
    > Anyone from IBM want to exactly explain how does this improve my productivity and reduce the TCO, please? No, I'm serious. I want to know.
    >
    > Or here's a small sample of other issues, only off the top of my head, which we faced over the last year.
    >
    > - XA exceptions when using more than one Oracle database in the same transaction? Check. (Fixed in WS 5.0.1.) That caused the whole team to first scramble frantically to diagnose the issue for two weeks... then wait another 42 days for IBM to fix it.
    >
    > - Severe performance problems in the DataSource when using JAAS? Check. (Fix PQ79683.) More time lost, and more teams from several projects scrambling to find out why that promised land of scalable J2EE architectures... doesn't scale.
    >
    > - ClassCastExceptions due to an ORB bug on Solaris, when two session beans call each other? Check. More time lost diagnosing IBM bugs, and one huge administrative overhead to keep the application working in the meantime. (Unnamed fix from IBM, which basically made the server crash upon start-up. Obviously never actually tested on WebSphere.)
    >
    > - Exceptions being silently caught and replaced by other (completely wrong) exceptions? Check. E.g., what should have come as a ClassNotFoundException at deserializing, in WebSphere comes back as a NotSerializableException. Heck, yeah, that's got to improve our speed at diagnosing problems. (Not fixed.)
    >
    > - Wrong or misleading error messages in the tools? Check. E.g., the Tivoli Perfomance Viewer says that no server has the performance monitoring turned on, instead of saying that the password is wrong. (Not fixed.)
    >
    > - WebSphere 5.0.2 filling the logs with NumberFormatException lines when performance monitoring was enabled? Check. (Unnamed fix from IBM.)
    >
    > Etc, etc, etc. Seems to me like WAS 5 alone is enough reason to be angry.
    >

    You sound like me last week. So glad I'm not alone...
  23. above the flames[ Go to top ]

    "I must admit though that the phrasing above is very diplomatic..."

    And I must admit that the response was at least as diplomatic.

    Cristian,

        I will admit that I believed you were bitching about J2EE with Visual Studio humming just below the browser. I think you answered my question while keeping above the flames. I thank you for that. I apologize for the insult.

    Sincerely,
    jonnie savell
  24. I shouldn't have been so cranky to start with. But, well, after a day of keeping deploying on the aforementioned test system, to find out why something that worked perfectly in a Windows WAS 5 installation, silently ignores all but the first message on Solaris... you get the idea. It's one of those moments when the Dark Side ;) looks very very tempting.
  25. Yes Sun did beat the crap out of M$ with Java that is why they copied
    c#. I have not seen any innovation from M$ except coping from other vendor.


    To us .Net server and M$ transaction server is a joke with full of bugs can handle high tps.
    And good old VB single thread is great innovation from M$.


    Webpshere 5.0 runs great in our book.
  26. Bingo[ Go to top ]

    You can replace the words 'Sun' and 'J2EE' with the words '.Net' and 'MS' and it works pretty well.

    .Net is a mixture of good and bad. The bad being that Microsofts hype machine pushed a lot of projects to use a bunch of buzzwords that they didn't actually need. (E.g., let's be honest, about 90% of the projects who use .Net didn't actually need them, other than buzzword value.)

    See.