Novell’s CEO: Painted Into A Corner?
Novell CEO Ron Hovsepian is calling for a standardized way to develop Linux applications across multiple distributions (Novell, Red Hat, etc.). Hmmm. Hovsepian’s motivations are easy to understand — Novell badly trails Red Hat when it comes to Linux application support. But will anybody answer his call for help?
That’s doubtful. Hovsepian painted Novell into a corner when the company agreed to partner with Microsoft on Linux-Windows interoperability last year. Some mutual Microsoft-Novell customers are certainly benefiting from the deal. But the partnership’s focus on patents upset many members of the open source community.
The VAR Guy thought the rift between Novell and open source advocates would settle down after a few months. But during Ubuntu’s developer conference in July, many attendees once again expressed disdain for Novell’s business relationship with Microsoft.
Still, there may be a silver lining. During the Ubuntu conference, Canonical CEO Mark Shuttleworth called for major providers (Ubuntu/Canonical, Novell, Red Hat, etc.) to synchronize their major Linux releases, starting in 2010. Initially, none of the Linux providers answered Shuttleworth’s call for discussion. Maybe Hovsepian should give him a shout and find some common ground between the two companies.
I do not understand why this is a big deal. Those that deploy these systems watch the FOSS market. Syncrinising sounds like some thing that that would make FOSS purchasing fool proof even for CEO’s. I tell ya the higher up they are the less they know. And my for ever favorites “Those that do not know, pay for it.” and “You will never know what you refuse to understand.”
This is silly. The Linux Standards (now “Linux Foundation”) base “specifies for example: standard libraries, a number of commands and utilities that extend the POSIX standard, the layout of the file system hierarchy, run levels, the printing system, including spoolers such as CUPS and tools like Foomatic and several extensions to the X Window System.”
Want more? There are projects “upstream” of LSB, such as freedesktop.org, that eventually/sometimes become part of the LSB.
Novell would do a lot to repair the self inflicted wounds to their reputation if they assigned a few talented engineers the LSB, instead of pretending the LSB doesn’t exist (I don’t sense any Novell-gt;LSB hostility, just an ignorant CEO far out of touch with his engineers).
That SuSE feels left out is understandable (my company has no customer complaints over the fact that we only support CentOS, Fedora, Ubuntu and Debian). That they would perpetuate the problem by not playing ball with standards bodies… that’s just silly.
Without it the ISV market will ultimately stay on Windows or a few on mainly one distro instead of all. With standardization ISV’s certify to that standard. Every distro which counts will support it and hence able to tun the application. ISV problem solved. I know that Ron and Markus Rex and many others at Novell have been working on this for a very long time.
Only one big problem with this article. It transpires of Ubuntu propaganda. Ron however is less into propaganda and more into business, than Mr Shuttleworth, whose Canonical seems to never be questioned on how much money it looses in business. Novell is a near billion dollar revenue company. How much revenue makes Ubuntu
Supporting the Linux foundation by lending Markus Rex to foster this needed standardization is a brillant move and certainly more action that Mr. Shuttleworth and his constant verbal escapades. Rons pointed speeches and public appearances are just what we all need to keep the windows folks talking about Linux and trusting in Linux. That is at least what many believe, inside and outside Novell, especially in the business computing field.
Markus has pushed for standardization for a long time. Mr. Shuttleworth probably was still poor and not in outer space with his mind back then. If he can convince the world that he invented the desktop distro concept for humanity then the propaganda obviously worked.
brotherred, I doubt you really understand what “higher up” means on a business context from your comments. Ron certainly excels in energy and will to listen to everyone who manages to talk to him. Next time you are able to, please do. He is a very inspiring person.
The VAR Guy loves a good debate between readers. The ball is in your court, Brotherred. As for Ubuntu: We may not know Canonical’s revenue figures … but the company’s big win with Dell is not to be underestimated. The VAR Guy is a Windows veteran and Linux novice who nevertheless purchased an Ubuntu system from Dell. And he loves it.
Hovsepian is repeating what so many others before him have said, which is, making it easier to packages apps for multiple distros is good for all distros. The problem is, he has never figured out FOSS. He wants the distros to adapt to a solution produced by a committee, or worse.
I am a maintainer of the SourceForge project, RenaissanceCore IDS. It is a bit complex (4 related components, including a PostgreSQL backend), so we don’t want to just release source code. I built Debian Etch packages for each component and now we are working on RPMs. Here is my experience and what I think would be a possible solution:
1) The LSB is a nice concept, but doesn’t go far enough to produce value for developers. It requires a very limited number of libraries, but because one of our components uses libxml2 and libpcap, it is not LSB compliant. The LSB solution is to statically link those libraries, which could work in our case, but for many projects would not. On the other hand, to specify a wider list of library versions is also not realistic. And there is a lot more to packaging than just library dependencies, much of which the LSB does not even address. So the reality of the LSB is that it provides a minimal amount of consistency between distros, but not enough to insure an application can be installed on any LSB compliant distro.
2) *buntu is based on Debian unstable. This means that the version of glibc is a different between Debian Etch and Feisty Fawn. This means that an app built for FF very likely won’t run on Etch, and one built for Etch might crash on FF. In RPMland, it’s essentially impossible to build a single package. Building a package for a distro means installing that distro and learning how to set it up, when all you really want is the specific build of the libs.
3) Our UI is written in Java to be run on many platforms (the LSB doesn’t mention Java, Perl, PHP, etc.). We are very happy that Sun is GPL’ing Java, but there is still a problem. Sun and IBM have done to Java what they did with Unix. There are 2 UI libraries: AWT/Swing and SWT/JFace. If a Java app is written using SWT/JFace, those libraries must be installed separately from the Java VM, and they require gtk or motif libraries as well. (I am mainly a C programmer and didn’t make the decision on using SWT/JFace in our app, but have read several discussions/arguments about the pros and cons of each, and they essentially boil down to personal preference–ie. the bugaboo of choice.) It would be extraordinarily nice if the Eclipse Foundation and Sun could work together to make SWT/JFace a standard part of the JVM, but I’m not holding my breath.
4) Because we use a DB backend, we have to customize our SQL scripts for different versions. SQL has been around for a long time, so queries, inserts, deletes, etc. are very consistent. However management commands, such as creating users and giving them access to data, are not only different between DBs, they may be different between versions of the same DB.
Considering that these issues are from just 1 project, I believe that attempts to standardize distros are useless. Also, I don’t expect any of the universal installer projects to be successful because they need total buy-in from the major distros, who are only looking at a new set of bugs to support.
Instead, I would like to see a common set of procedures for building packages on any distro. In other words, a high-level abstraction layer for package building tools and an app implementing it. A single package definition would output a valid package for any supported distro. This is something the Linux Foundation (maintainers of the LSB) should undertake, as opposed to a SourceForge project, because of the resources required and cooperation from distros. A HAL gives the distros new apps that match their existing packaging requirements, so hopefully many would cooperate.
My initial specifications for such a HAL would be that each distro supply the following:
A package of all development libraries
A complete description of the dependency definitions for all versions of support projects in the distro, such as DBs, web environments (ie. Ruby on Rails), JVMs (there must be a least a half dozen), etc.
All package building tools and the doc on using them
Then the project would be put in a directory tree so that source code, doc, configs, etc. would be found by the HAL app, which could be a Perl script. For each specified distro, the source would be built using that distro’s libs, and then a valid package would be created. Since I have had to build my packages several times, I have built several scripts to automate as much as possible, so I know that this is doable.
Later . . . Jim
RenaissanceCore IDS, check it out at:
http://sourceforge.net/projects/renaissancecore
Hovsepian’s BIG problem is that what he SAYS (“There is NO MS IP in Linux”) is opposite to what he DOES — pay a ROYALTY to Microsoft for each copy of SLES sold. Ballmer called it the “IP Bridge”. Microsoft pays Novell $300M to “admit” that SLES, and hence Linux, contains MS IP, and Novell agrees to pay a percentage of the income they receive for selling SLES, even though that amount will probably never equal the $300M Microsoft paid Novell.
To “sweeten” the deal for Novell, Microsoft issued a lawsuit threat to every Linux user NOT running SLES, and to every FOSS coder whose contributions do not make it into SLES (not openSUSE). Hovsepian obviously thought this threat would scare a lot of Linux users to use openSUSE, if not SLES, even though openSUSE users are NOT under the Novell umbrella of protection against a possible MS lawsuit.
It is also obvious that Hovsepian, who claims he couldn’t sell Linux against Windows servers even though RedHat has no trouble doing so, under estimated the outrage of the FOSS community. While Windows fanbois and Novell employees side with Novell, which spends a chunk of money to see that their views find outlets in the media, the majority of the FOSS community has not respect for Novell.
Hovsepian demonstrates again, in the “fewer distros” rant, why he couldn’t sell Linux against Windows — he knows little about Linux and believes even less. Born and raised in a Windows culture at IBM, it is all he knows. IF he is serious about diminishing the number of distros I would recommend what Brandioch Conner recommends: eliminate SLES and openSUSE.
What Hovsepian wants is a way to use a single tool to write a single application that will run on ALL major Linux distros, which would make commercial distro makers business much easier and more profitable. They tried to force this issue by standardizing on GNOME, which is built upon the GPL’d GTK+ toolkit. KDE is built using the GPL’d version of the QT toolkit. They can write proprietry apps using GTK+ and not pay a license fee, but they’d still have to share the source if asked for it. If they used QT they’d have to pay a license fee to be able to write proprietary apps, but they would not have to share the source. Their attempts to force Linux users to GNOME isn’t working as planned because KDE resides on the majority of Linux desktops.
The problem is deeper than that. GTK+ is written using C and some “signals amp; slots” technology borrowed from QT. QT is written using C++ and its object capabilities and Trolltech’s “Signals amp; Slots” technolgy, which makes writing callback functions a piece of cake. I doubt the two camps will merge. Why should they?
Then there is the Portland Project, which is attempting to release a development tool which will allow what Hovsepian wants: write once, compile once, run on any Linux distro. But the easiest way to do that, and its been around from the beginning, is to create a static binary which does not rely on the existence of libraries in the user’s distro but carries all of its libraries within the binary executable.
And yours makes you seem like a shill for Ron Horsesapian.
Im surprised you didnt call him mother Theresa.
If Canonical or Red Hat talk I listen because they didnt sign that FUD deal. Your buddy Ron?
I ttrust him as much as Kevin Carmony.
[…] read more | digg story […]
[…] move into the Linux market has had little #8212; if any #8212; impact on Red Hat. And the Microsoft-Novell alliance pushed many open source advocates into Red Hat#8217;s camp. Challenges: Unlike much of the open […]