Here is part 2 and part 3 of the AlwaysOn interviews of Miguel and Nat from Ximian and Chris Stone, Novell CEO. To find out more about why Novell made such a sudden change in direction, and what their plans are for the future, IBM talked to Chris Stone.
Novell Would Eclipse Sun
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The pun is getting *really* stale.
> IBM and Novell have had a long relationship, sometimes it’s been up, sometimes down.
I do hope they play nicely together. Put an end to UNIX / OS wars. It makes sense even from a ‘business’ point of view.
i belve that in few years , every one will be jumping on the Linux Wagon , after All Linux is only the Kernel , with IBM ,HP ,Dell ,Novell , and Other even MS-Soft
with VM on top ither ( JAVA or .net (mono ) )
and every vender offring thir middeltir soulation on the top , the is Linux free anymore becoues you will buy for any licince fo The OS but insted for the software that comes on top of it
they will start to charge us per users for the thir prpority software , on top of the Free OS (kernel ) that all of them support , wander what will be at the End of the Road ????
Exactly right. The OS is a commodity(which MS does not like) and your revenue is built up on higher-level services. I could see Novell integrating Mono into their desktop so that you have a RAD developer solution along with a top-notch/stable OS underneath.
IMHO, the problem with linux for developers(in particular, those coming from a windows background) is that you have C, with some C++, as the least common denominator for development. I’m talking about desktop here. You’ve got some java work, a little python, ruby, perl, and whatever here and there, but none of these have been RAD or powerful enough(except for java) for really doing large, complex apps that aren’t a nightmare to maintain. C is a fine language, but for the vast majority of apps you don’t need to get that low-level. I consider Ruby and Python to be still somewhat fringe and slow. Perl is basically a mess to maintain and it looks like Parrot is backed up into the next century for anything serious to come out of it.
Personally, I wish Novell would use the KDE desktop as a base for their future efforts, but because of the licensing issue and whatever other issues it doesn’t look like it is going to happen.
> You’ve got some java work, a little python, ruby, perl, and whatever here and there, but none of these have been RAD or powerful enough(except for java) for really doing large, complex apps that aren’t a nightmare to maintain.
Glade and QT Designer (Someone will correct me if I’m wrong).
Umm a large, complex app created with pointy clicky ‘RAD’ wizards is *not* maintainable. You’re probably better off writing the backend and doing the GUI using a tool.
Did I understand your point correctly? RAD tends to be a very vague term.
From Part 2:
> They said something the other day publicly, and I don’t
> remember where, about how if SCO drops out of the anti-Linux
> battle, they’d pick it up—or something like that.
Does anyone actually believe this? I’d be very interested to see the source (if one actually exists).
> You’ve got some java work, a little python, ruby, perl, and whatever here and there, but none of these have been >RAD or powerful enough(except for java) for really doing
>large, complex apps that aren’t a nightmare to maintain.
>Glade and QT Designer (Someone will correct me if I’m >wrong).
>Umm a large, complex app created with pointy clicky ‘RAD’ >wizards is *not* maintainable. You’re probably better off >writing the backend and doing the GUI using a tool.
>Did I understand your point correctly? RAD tends to be a >very vague term.
What do you mean by big, 1 million lines?
We regularly maintain GUI apps which have 300K lines, without the rad tools maintenance would be very tedious and long winded (and hence more expensive).
> We regularly maintain GUI apps which have 300K lines, without the rad tools maintenance would be very tedious and long winded (and hence more expensive).
Heh, that’s pretty big
Cool. What language(s) is it written in? What tools do you use? How many bugs does it have
How easy / hard is it to debug if you don’t even look at the control flow?
> We regularly maintain GUI apps which have 300K lines, without the rad tools maintenance would be very tedious and long winded (and hence more expensive).
>Heh, that’s pretty big
>Cool. What language(s) is it written in? What tools do >you use? How many bugs does it have
>How easy / hard is it to debug if you don’t even look at >the control flow?
They’re written in Delphi. This was a very cost related decision, applications had to be completed in 6 months. Something like C++ or even Java would have increased that time and we’d be over budget. All software has bugs, but tested software has fewer bugs! Debugging in Delphi is like any other modern IDE, setting breakpoints etc. One productive feature I like during debugging (present in most modern IDEs) is watching values for variables by just hovering over the variable name, simple but quite effective.
There is no control flow in the GUI section, the RAD simply generates code to layout the widgets, you assume that the rad tool has got it right. In Delphi layout code is hidden in the dfm files, in C# (or Java) that code is visible in the main program. Personally I prefer that it’s hidden since I find that such code gets in the way and there can be an awful lot of it in a complex form. The last thing I want to do is think about how to layout a GUI programatically, much prefer to concentrate time on the backend which is where the added value goes. Hence a rad tool is very useful. For dynamic forms, widgets are generated on the fly, but debugging them is simply stepping through the code.
Granted a purist would like to get out emacs and hand code everything by hand and debug using printf statments (we still do that for our linux portable C code!). In cost conscious environemts idealism has to be tempered with practical issues such as money, time, ease of maintenance etc.
> Debugging in Delphi is like any other modern IDE, setting breakpoints etc. One productive feature I like during debugging (present in most modern IDEs) is watching values for variables by just hovering over the variable name, simple but quite effective.
Nitpick. If that’s what you’re doing, something’s not right. Watching variables in a debugger is a very primitive form of debugging, especially if you have the source.
> In Delphi layout code is hidden in the dfm files, in C# (or Java) that code is visible in the main program. Personally I prefer that it’s hidden since I find that such code gets in the way and there can be an awful lot of it in a complex form.
Yes, you need to do the layout manually in Java. Some IDEs do help (but the resultant code can be UGLY). However it is possible to have a a complicated layout in let’s say, a dialog box with a bunch of widgets, with *sane* *parseable* code. Use BoxLayout. Nest boxes. Avoid GridBagLayout and family.
And I’ll hazard a guess that even if you do it by hand, the time required to do the layout is a fraction of the total time taken to write the application. I think you’ll agree.
EmacsOS? No thanks
Yes they will.
“Watching variables in a debugger is a very primitive form of debugging, especially if you have the source. ”
Care to elaborate how this is in fact primitive?
VStudio collapses auto-generated form codes by default, which in most cases hides it from harm’s way.
Most modern Java IDEs come with fairly sophisticated GUI design kits. Swing layout managers are a bit quirky, but once you get the hang of it, it is actually pretty powerful.
Stone: What was the thing Jonathan Schwartz said the other day, Nat? Linux is not or will never be a strategy for Sun on the server?
Friedman: He said, “Let me be perfectly clear about our Linux strategy: we don’t have one.”
Stone: Yeah, “We don’t have one.” Then the next day they announce things like Mad Hatter or the Java Enterprise, or whatever it is, which is a Linux desktop. So it’s extremely schizophrenic.
Nice to see that we have yet more people making patently false statement. The original interview with Jonathan Schwartz was along the line of having a Linux stratergy which tied into the server orienated questions being asked.
HP doesn’t have a Linux stratergy. Simply loading Linux onto servers isn’t a stratergy, that is simply meeting demand and ensuring you hold onto your market share. Formulating a business plan involves more than that. It involves developing a software line, hardware and operating system stress-testing, services and consulting then there are the hundreds if not thousands of businesses who work with SUN in relation to system integration.
SUNs stratergy is pretty simple, Solaris x86/SPARC on the server and Linux on the desktop. If Stone and Friedman can’t understand something that simple then they should resign from their job and let someone with a clue actually take the reigns.
Btw, you want me be impressed about IBM, how about IBM actually moving their client side application line up natively to Linux and actually start PUSHING the adoption of Linux on the desktop. If they’re so gungho about that whole situation, why don’t they offer Think Centre PCs pre-loaded with Linux?
Atleast with SUN you know where you stand, they’re a UNIX company, plain and simple. What about IBM? on one hand they praise Linux and yet they turn around pushing Windows 2003 and Windows XP. Its like HP, on one hand they scream the praises of Linux then suddenly appear on a SCO product roadshow.
Oh and friedman, maybe you should actually learn what schizophrenic is. Btw, it doesn’t mean “multiple personalities”.
ChocolateCheeseCake,
“Nice to see that we have yet more people making patently false statement. The original interview with Jonathan Schwartz was along the line of having a Linux stratergy which tied into the server orienated questions being asked.”
“SUNs stratergy is pretty simple, Solaris x86/SPARC on the server and Linux on the desktop. If Stone and Friedman can’t understand something that simple then they should resign from their job and let someone with a clue actually take the reigns.”
You are being incredibly obtuse, or worse, you missing the outright obvious. The quote from Jonathan Schwartz:
“Let me be perfectly clear about our Linux strategy: we don’t have one.”
is about as misleading as any statement can be. Linux nivilates the classical distinction which has defined Sun’s market for years. Sun view computers as being subdivided in three categories: servers, workstations and consumer desktop pc’s. Sun specialized itself by focusing on servers and workstations, thereby creating a market niche in wich Sun performed, economically, quite well. In recent times Linux has obviated these, once clear, delineations. The strength of Linux and it’s weakness is that Linux *is* no single thing- Linux can be used as a server, as a workstation and as a desktop pc.
Sun faces a true conceptual conundrum in dealing with Linux-if it accepts Linux’s redefinition of market lanscape, where commodity hardware can be implemented universally beyond the bounds of the commodity market, Sun must reliquish its hold on the niche market which has defined and sustained Sun.
The quote from Schwart struck everyone, not just Miguel, Friedman and Stone, as being not only outrageous but quite duplicitous. NOT having a strategy in regards to something IS itself a profound strategy and saying such is *always* a strategical move albeit rather covert and obscure. Schwartz may have *meant* for his quote to be taken in the context of Sun’s server strategy, but the rest of the world which is no longer operating in the pre-defined context within which Sun operates *must* be confused due to the inherit contradictions which are abundant in Suns behavior regarding the entire x86 world.
Sun is only now beginning to reappraise its two-stepping regarding Solaris on x86, but only because of Athlon 64-not because of the thousands of Solaris x86 developers which have been screwed over time and again due to mismanagement and indecision on the part of Suns “managment”. The very next day following the publication on this quote from Schwartz Sun *pre*-announced the contract with China for *umpteen* gazillion Java Desktop Systems.
So- here is the situation. Sun has *no* Linux strategy, and informs the world of the single largest Linux contract ever seen, in fact a contract larger in terms of the numbers of installed seats than anything Sun has ever done before in any of their markets. hmmm. Now Sun is apparently waffling on their choice of SuSE as the basis for the JDS. Well Sun also did this with Redhat before. So now Sun has some thousands of seats with various Sun modified Linux distributions which are non-supportable-neither by Sun or Redhat or by SuSE. Brilliant.
This behavior is not unaptly termed “schizophrenic”. Sun, and I mean their management, does not have mulitple personalities- they seem to have a very deep personality disorder-the former being the case when one has multiple in-tact sustainable, yet, irreversibly divorced personalities, whereas the latter is commonly concurrent with schizophenia. Sun has many brilliant and talented engineers and has produce many great products over the years, yet they are in the midst of a deeper identity crisis, which admittedly cannot be easily resolved.
So in your infinite wisdom please tell me, or perhaps more to the point-tell Schwartz, what this *clear* strategy regarding Linux is-
Solaris x86 vs. Linux
Sparc vs. Athlon64
desktop vs. workstation vs. server
commodity hardware vs. propietary hardware
open source vs. supporting SCO.
hmmm looks mighty clear to me….
>Nitpick. If that’s what you’re doing, something’s not >right. Watching variables in a debugger is a very >primitive form of debugging, especially if you have the >source.
I’m not sure what you mean when you say that watching variables is a primitive form of debugging, surely one needs to know the values of your variables during a debug? I’d be curious to know how you debug with out knowing the values of the variables?
I agree with you however that the time taken to layout forms is much smaller than the backend coding (unless their dynamic forms). However, using a layout tool to do the gui means it just one less thing to think about.
> surely one needs to know the values of your variables during a debug?
I assume you’re doing this by setting breakpoints, and then single stepping or ‘run to breakpoint’ and then watching the variable contents.
Well, this way you’re doing data flow analysis, *not* control flow analysis. What you should be doing is thinking ‘Why is this variable taking this value?’ instead of ‘What value is this variable taking?’.
Obviously you need to *see* the variable contents. Which is easily accomplished by printing to the output window or console. And which is a lot easier / faster than the breakpoint-step thingie.
Even better, prevent illegal values by sprinkling assert() statements while coding, and *remove* them once the code works.
I don’t know if I’m clear, but basically what I’m trying to say is – you should be spending more time looking at the code than the data when debugging.
> surely one needs to know the values of your variables during a debug?
>I assume you’re doing this by setting breakpoints, and >then single stepping or ‘run to breakpoint’ and then >watching the variable contents.
>Well, this way you’re doing data flow analysis, *not* >control flow analysis. What you should be doing is >thinking ‘Why is this variable taking this value?’ >instead of ‘What value is this variable taking?’.
Well of course, but before I can ask why is this variable taking this value, I need first to know what value is it taking. I think you can assume I am asking why a variable has a certain value, if I didn’t I don’t think I’d be able to debug at all.
>Obviously you need to *see* the variable contents. Which >is easily accomplished by printing to the output window >or console. And which is a lot easier / faster than the >breakpoint-step thingie.
I used to do it that way, and sometimes still do, but for quickly seeing what is what, hovering over variables is at times useful and quicker. I use it now more often by print stuff to the console.
>Even better, prevent illegal values by sprinkling assert>() statements while coding, and *remove* them once the >code works.
You right there, asserts are something I don’t use enough.
>I don’t know if I’m clear, but basically what I’m trying >to say is – you should be spending more time looking at >the code than the data when debugging.
True, but modern ides mack it so easy to debug.
So in your infinite wisdom please tell me, or perhaps more to the point-tell Schwartz, what this *clear* strategy regarding Linux is-
Solaris x86 vs. Linux
Sparc vs. Athlon64
desktop vs. workstation vs. server
commodity hardware vs. propietary hardware
open source vs. supporting SCO.
Buggered if I know why I respond to such simpletons; Got time to burn so I might as well.
SPARC is being pushed further in the high end, >32 configurations where as Opteron is being adopted for the 1/2/4 way configurations which are the sweet spot in terms of volume sales.
As for the operating system, it is Solaris on the server and Linux on the desktop. Solaris strength is its brute industrial strength reliability but it lacks the bells and whistles on expects from a modern desktop operating system.
Linux is for the desktop which coupled with GNOME and numerous other opensource technologies can provide a viable desktop solution for those looking for a low cost alternative to Windows/Office.
Linux on the desktop and Solaris on the server. Read and repeat until it is ingrained into your subconscience.
As for commodity hardware, you are really clueless. Look in you average SUN workstation today and name a proprietary component, infact, go into ANY UNIX vendors workstation or desktop today and name a proprietary component.
As for “supporting SCO”, bull crap, the only two things SUN has said is, “we have a very comprehensive license” and “we must respect intellectual property rights and contracts”. Also, it seens convienent that like most Linux users you failed to acknowledge the marriage of convienence between HP and SCO.
Chocolatecheesecake,
You did not address the issues I raised. It may be that you are clear about Suns’ Linux strategy but I don’t see any proof that the head people at Sun are sure about their own strategy. I made no comment whatsoever regarding HP. Sun has played a fence sitter in the SCO vs. Linux ordeal and uses this ordeal to their supposed advantage-after all they don’t *do* Linux. Sure Sun is less dependent on parts which they alone produce, compared to a few years ago, yet their propietary hardware and assembly is still one of their key selling points. I do not hate Sun, ie. their management, but I am not alone in finding their NOT-strategy regarding Linux more than a little duplicitous….
I hope it turns you on to refer to people as simpletons, sweet wet dreams…..
karl, what do you call this:
http://www.sun.com/2003-0930/feature/
Just because YOU don’t take the time to listen to SUN’s management doesn’t mean that there are other people out like you. Handle the fact that SUN is succeeding. They’ve already won customers over and still winning more. Instead of coming out with so-called “business tips”, how about looking at the results. The results speak for themselves, and the proof is in the pudding. SUN is winning new customers and keeping their old ones.