Slashdot Mirror
Red Hat, IBM Partner to Certify Apps for Linux
robyannetta writes "British tech site
Microscope has an interesting article talking about how Red Hat and IBM will join forces to help software suppliers certify their applications for Linux. The program is designed to make it easier for suppliers to migrate their software to Linux, and will also give IBM and Red Hat a boost by enlarging the pool of applications certified to run on Red Hat Enterprise Linux with IBM hardware and middleware. Yet another example of creative business foresight that keeps both Red Hat and IBM in the black."
something smells fishy here. I would have thought IBM would have partnered with Novell Suse (to certify apps), since they are more close to Suse than RedHat. And I think they made some serious monetary contribution to the Suse project as well.
Consensus is good, but informed dictatorship is better
I RTFA but it wasn't clear to me what this means in practical terms, so excuse if the following sounds like trolling.
I can see a future where if a linux app isn't certified by this venture (or some other venture if not), then PHBs will refuse to have it on their systems, even though it may be perfectly good for the job, just like with the Red Hat Certification programme. A PHB will see that a potential job candidate is not Red Hat Certified and think that they know jack about Red Hat, or linux for that matter.
It's good to see IBM's continued interest in improving and enriching the open source community through its business initiative. Equally so on Red Hat's count, though we shouldn't be surprised by it. In time, I suspect this sort of certification process will win Linux the mainstream acceptance it needs to make waves in the desktop market.
There is a danger, though. As corporate certification and such becomes a necessity for developers, there will be a corresponding dependence on such higher powers. In the effort to pander to certification boards, innovation and free pursuit of new application and programming paradigms may be squelched.
We have to keep in mind that initiatives like this one can be a mixed bag. I am reminded, somewhat chillingly, of stories of the end times in which a world government, or perhaps a huge corporate monopoly as IBM may become (with the help of Linux, ironically). It is disconcerting to think that these sort of certification programs may ultimately lead to the sort of domination and monopolization the applications were made to fight.
In the meantime, however, let's be sure no open source application is left behind.
A Proud Member of the Reality Oriented Community.
This resembles Free the software, sell the brand. Of course, the brand being sold is not really Linux; it is actually IBM/Red Hat, but the idea is the same.
*is run over by rotten tomatoes*
IBM's not too worried about staying in the black. For some reason, some people seem to confuse IBM with a struggling OSS supporting company.
Brathat
(we may have come up with a new language here)
This is not the right way to speak to customers. Generally they don't like to be fed loads of BS.
It isn't certifying for linux, it's certifying for RedHat Linux on IBM hardware.
That almost certainly will count for something in the enterprise, where people will have lots of money riding on whether an application works-- although it may just be a cash cow for IBM designed to convince app developers to pay for expensive certifications. Either way though it won't be very useful in general.
What we need is something more widely practical, for example a certification authority that certifies distributions and applications as being compliant with the LSB. (If nothing else, commercial games on Linux will continue to go nowhere until this happens.) Then again, we kind of need a more meaningful LSB before there's any point to this.
Dont you mean rather than certify the programs for linux certify them for Redhat?
Thats really what redhat is all about.. If you want to use enterprise linux your stuck with old versions of software that often may not have the functions et that you require (see Redhat ES3.0 with PHP / GD etc.
Maybe Redhat can supply newer binaries and source packages so that you can still get support for newer revisions of software if you require it. Makes it much more attractive as a corporate package then.
Well I'm working in the oil industry and they'd be pleased with certified products. Actually, they'd pay any quantity of money for a certified OS. We are using Red Hat because it has a good support and certifications here in Mexico. I think this is a good move for Red Hat.
Free iPods, no trick, no steal, (almost) no pain:
This development is exactly the kind of business operation that the P2P open source community can do better than a centralized partnership like RH/IBM. Their announced certification programme is just a formalized test suite on a spec'd reference platform, branded by a company with a vulnerable reputation, and a sueable issuer of guarantees. That's the traditional trust model for accepting risks. But the distributed Linux community has the advantage of massive parallelism, while RH/IBM shares the usually denied flaw of fallability.
2 MB.Sony-CD/DVDR etc. A grid of combinations of HW, distros, and package sets, with test results ranging from verbose STDOUT/STDERR to "PASS/FAIL". It's a large, multidimensional dataset that's constantly increasing. But that's exactly where the massively parallel open source community has the advantage.
Various distros bundle the Linux kernel with GNU and other packages, built into executable binaries for certain hardware architectures. Another layer can be built on this foundation: standardized test suites, and specs for HW configs within the architecture. Like i386.nVidia-GeForce2.3Com-3C509.SMS-EIDE.SDRAM-51
Every time someone installs a package, they generate data for this database. Why not upgrade the "make" util, wrap it in a reporting util, or distribute a component that "make test" calls? Like Mozilla's crash reports, including HW configs. That open DB can offer the kind of searchable install results that everyone's now running ad hoc, by Googling their build error messages. The database can have a set of certified HW/SW/config parameters that work, for each installable package.
Submit and publish the data under the Creative Commons license. Fund the servers by running a subscription service that proactively mines the install data, fixing problems popular in the field or popular with clients. That company, the Red Hat of "open installation", can compete directly with this RH/IBM venture. Its economies of scale will likely eventually attract RH/IBM itself to use the open database.
The open source revolution is just getting started. Leveraging the freedom of exchanging the source code with tools that combine the power of the community is the chief advantage over proprietary source. If we just crudely install packages, and post build failures to arbitrary mailing lists, we're just taking from the community, without giving back. That community communication is the central strength. Without using it, we're just wallowing in an academic sense of freedom that will be crushed by proprietary organizations that are better organized and more competitive. Now, in the beginning, is the time to ensure the balance is set in our favor.
--
make install -not war
What moral, technical or otherwise authority do IBM and Red Hat have to 'certify' Linux apps?
(-1 Troll, here I come.)
Certification? We don't need no stinking certification!
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
I think you have a point here. Linux needs to become more standardized. We need a unified package system and a standard UI/window manager/toolkit.
KDE and Gnome are too bloated, we need a simpler standard.
God, root, what is the difference?
1. increased use of oss in enterprise environments
2. the perception that oss is from an "amateur" community is removed
3. people will have someone to "trust" with regards to an application
some bad things i can think of:
1. they can corner certain apps with certifications and leave others out that can affect development
2. will they have enough resources to test every oss around? if not, then it would be unfair
3. they can use the certification process to promote their own developed or preferred applications leaving the competition out
my thoughts, and the list will continue. but i do hope that this will focus on the good part and a step in the right direction.
Live your life each day as if it was your last.
"There is a danger, though. As corporate certification and such becomes a necessity for developers, there will be a corresponding dependence on such higher powers. In the effort to pander to certification boards, innovation and free pursuit of new application and programming paradigms may be squelched."
Hardly. You go and innovate all you like. There is no corporate certification anything that's going to stop you from doing anything you want to do.
Do something useful and people will buy it and then you can either work with the certification boards as your friend or go your own way.
Err Red Hat has a very well documented file system standard and also linux doesn't use dll's.
Regards,
Steve
Then what the hell are all those files that end with ".so"?
I work for an University and have asked alot of the vendors of research applications why they don't provide support for Linux. The most frequent excuse given is "because Linux does not 'support us.'" Half the time they refuse to back-up the claim with any specifics. The other half the time it is because their application uses Motif v2 and will not work with lesstif so porting would cost too much or else they would have to also force customers to pay an additional cost for getting Motif. Ok... but then Open Motif came out, and the same vendors complained that it didn't come already packaged with any distribution and it was hard to get compiled with some versions of GCC. Then it did start shipping with the major distributions and then the vendors complained that the OpenMotif license had a "Open Source requirement" clause. Then the OpenGroup posted a FAQ explicitly stating that close source commerical applications can legally link against OpenMotif. And the vendors are looking into it... and still looking into it... and now considering it... and back to looking into it...
.com, we where hoping they would continue to support our six figure investment in Sun equipment despite being a .edu which spends less than six figures with Sun during an average year. One year we ran out of file system space on a system and requested a quote for a new external disk array. The Sun sales person "understood" it was very important to get the quote before the budget committee meets and would get back to us by the end of the week. And then it was the "top item" for her the next week. And then the next week. This went on for over a month of phone tag and no quote. Eventually we where told that our sales rep. was on maternity leave and we should wait for her to return to get the quote since we where "already working with her on it." Even when we stated that the deadline was in less than 72 hours, we where told that there was nothing they could do. It was at that point that the head of technology for the University said to "get that Sun sh*t out of here." And we did. (We where able to get around the declairation for running Java only because IBM provides a JDK). So vendors are going to continue to explain (provide excuses) why we should be running Solaris or a commerical OS to use their app. and we are going to continue to not buy.
I can understand that IBM and RedHat are responding to surveys of what the vendors say they want/need to support Linux. But how much of that is just a responce to the vendor's excuse of the day? How many vendors are actually going to jump at this and declair that this is *really* the show-stopper issue keeping them from porting to Linux? My guess is at the end of the day, there will be several vendors which point out that Solaris will be OSS and since their product already runs on Solaris, we should just use that.
But let me share you a little secret about how many of those vendors are able to make sales at our University. Back when Sun was busy putting th dot in
They're called shared object files. DLL is a Microsoft term.
Isn't choice one of the core good things about Linux?
Le français vous intéresse?
Great. So now we can go from a scenario where you can pick the hardware from any vendor, but your stuck with software from Microsoft to a scenario where you have to get your hardware from IBM and your software from Redhat. One of the major selling points of Linux is that your no longer dependent on a single vendor. I'd rather be dependent on a single vendor than dependent on two. At least with Microsoft, you know that they are going to support their operating system for a period of at least 5 - 7 years. With Redhat, who knows?
There is at least one gnu/linux distro that does not have any sort of DLL hell: G***oo. (I have obscured the name because I don't want the point of this comment to get lost in distro-flames.)
In the distro mentioned above, the package manager keeps track of what programs depend on what libraries, and can keep multiple versions of a library around if different programs depend on different versions. I don't claim to understand how it works exactly, but it is transparent to the user.
The only issue with this solution is that any program to be installed must be specifically packaged by the distro. If you want a Windows like install system, where the installer is basically independent of the OS, then you have two options:
(1) Put up with DLL Hell.
(2) Have each program include it's libraries with it so that DLLs are only used for very standard components.
Windows has progressed from (1) to (2) over the past 10 years or so. And with the hard drive space we have today, I don't really see this as a problem.
How could it work for linux though? First of all, gnome and kde would have to promise backward compability. Then any {gnome,kde} program could safely assume that all the {gnome,kde} base libraries would be installed. Anything else that the program required would be statically linked by the program, rather than dyncamically.
The package manager doing all the work seems like a decent temporary solution, but as the marketshare starts growing, a less managed solution will be necessary. I think that as gnome and kde mature, backwards compatibility will become more of an issue naturally. This will automatically help some.
The solution for the "enterprise" is simple. Run fairly standarized hardware and software. Pick a platform and pick a "house" distro, and core business applications for which the bugs have been worked out of the combination so you know how to support what you're using.
.
Oh, wait. .
(Oh, and while Linux certainly has dependency hell it doesn't have dll hell, which refers to the lack of version awareness, not simply dependency. In some respects dependency hell is the cure for dll hell. Ain't engineering tradeoffs a bitch? Get used to 'em though. They aren't going to go away.)
KFG
Linux certification for applcations is great (though I havn't got a clue what you'd do about GUI ones!), but what we really need is a linuc driver certification program.
Vendors don't like realeasing software unless they can get somones QA rubber stamp on it.
thank God the internet isn't a human right.
It doesn't always work, but it can do phenomenal things for customer loyalty if done right.
That would mean that companies would have to weed out the preditory business personalities, and actualy start thinking about a longer term that next quarter's report or the current bonus period. Followed to it's logical conclussion, they'd have to actualy service their current customers and quite salivating over emerging markets like India and China.
Apocalypse Cancelled, Sorry, No Ticket Refunds
They're called shared object files. DLL is a Microsoft term.
It's a term/acronym pertinent to most operating systems, although the file extension may be alien to unix systems.
See dlopen.
I am TheRaven on Soylent News
KDE and Gnome are too bloated, we need a simpler standard.
.mpg's play a lot better, and programs compile faster when I'm using WindowMaker rather than KDE. I like having the choise.
KDE and to a slightly lesser extent Gnome are far more than a UI-window manager-tk; they are application frameworks. I love my KDE, and there are a lot people who love their Gnome, but most of us will admit there are time we use a less resource intensive WM while doing certain tasks; on my slower machine
One of the reasons for the depenency hell isn't that the dependencies are hard to resolve, it's that the libs are used by multiple programs, and changing them willy-nilly can cause serious problems and instabilities.
Apocalypse Cancelled, Sorry, No Ticket Refunds
Ok, so what the hell do we do about SO hell?
They don't?
Good, then I guess Microsoft's rigged TCO studies aren't fooling anybody.
I would like to see real apples-to-apples comparisons between Windows 2003 and Linux (at least RedHat). I think that Linux, Windows 2003 and Solaris (particularly x86 Solaris 10, when available) are all interesting for the server space, each with their plusses and minuses. I assume that Microsoft doesn't commission fair comparisons between Windows and Linux because Linux comes out with a lower TCO. But if that is the case, why not admit that Linux is sometimes less expensive and sell based on features. Does Microsoft believe that the only thing they have to offer in the server space is a lower price?
I'm developing software that will remotely managed on Windows 2003 servers and I've been impressed by the stability of our HP servers with Windows 2003. I'm not impressed, however, with the fact that we'll be running Virus-checking software on a remotely managed server!
We're using Windows 2003 because the remote management software we'll be using (developed by another division) only exists for Windows. Up until now we've been a Solaris/Linux shop for the server space and a Solaris/Linux/Windows shop for the APIs.
Our last foray into running our infrastructure on Windows was back in the Windows NT 4 days. Oddly enough, there was no client uptake for that version. My guess is that by the time we had our software ready, our clients had enough experience with Windows NT to know that it shouldn't be used for servers requiring high-availability!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Certifications tend to test relatively benign stuff for the weak minded people who have no clue (but at least known they don't have a clue). It tests to make sure it indeed works under Linux or whatever. It tests to make sure it conforms to standards (doesn't install components in strange places, etc). It makes sure things like security protocols are correctly chosen (don't use MD4 when SHA1 is called for).
One thing certifications lack, however, is testing for bugs. And this not easy to do because the location of bugs are not documented in advance of discovering them. It would be nice to have a certification that there are no buffer overflows, for example. The OpenBSD developers are certainly working hard to eliminate exploitable bugs like that, but it can never be 100% certain.
The real problem with certification isn't exactly that it can't check for bugs like that, but rather, that it is a lengthy process and holds up replacement versions that correct such bugs that are discovered. This is especially so with government certifications which can sometimes take two years or more to complete, and applies only to single specific versions. The end result of requiring software be certified is to slow down your ability to respond to and deal with security exposures and critical malfunctions that are discovered after the fact.
Maybe what we really need is a certification of certification processes to help us choose a good certification process. And then we need a certification of the certification of the certification process. And so on. And so on. Yeah right.
now we need to go OSS in diesel cars
You do have a point this isn't certifying this for Linux but for their software and hardware. I do see where this could lead to the more widely practical, for example a certification authority that certifies distributions and applications as being compliant with the LSB. RedHat and IBM both are good about developing standards and there opening them up to the world. Unlike M$ that develope standards and then put the big patent lock on them. This is the one and only thing that Linux is lacking. A common standard to where applications are "load and go" on a box. That and the end of dependices hell. Maybe we are watching a birth of a good thing. I hope so.
Red Hat runs far fewer Linux apps than, say, Mempis or Libranet (aka Debian unstable & testing...but modified slightly). That means that if it can run on Red Hat, it should run anywhere.
E.g.: Take your copy of Alpha Centuari and try it on Fedora Core 2. Core dump, right. Switch over to the Debian boot on the same hardware and it works flawlessly. Ditto for sound card usage. (Fedora *recognizes* my sound card, it just won't play any sound through it. But Mempis and Libranet use it without problems.)
Therefore, if it can run on Red Hat, it can probably run on *any* Linux distribution.
Well, the logic needs a bit of work, but Red Hat is definitely amoung the pickier of distributions. And that's what you want for a certifier.
I think we've pushed this "anyone can grow up to be president" thing too far.
DLL's are windows shared libraries, nothing to do with linux (unless your talking about wine).
.sh or .pdf, as long as it contains a shell script.
Linux doesn't care about file extentions either (they are available in the gui's though for easy association, eg pdf to kpdf or whatever), and are used to show the user what type of file it is at a glance, but bash for example doesn't care if you end your file with
There isn't a dependancy hell on linux, if you use aptget or emerge (or if you use any package manager that supports dependancies, presuming you dont use suse rpm's on mandrake or whatever). I'm currently emerging kde (from the ~x86 branch of portage), its also installing dependancies for me. I did this with one command, and all im going to have to do afterwards is logout and login again for it to use the updated kde. Does that sound like dll hell to you?
Linux has support for filesystems with ACL's.
I dont know where you get your information, but maybe you should verify the reliability of your source.
Windows needs an easily scriptable installer more than linux needs a graphical one.
I'd like to see installshield burnt to the ground, the ground then sown with salt before finally digging the whole place up and throwing it into the sea.
What does Active Directory have to do with directory permissions? Bugger all. POSIX draft ACLs are better than the NTFS methods -- at least you can move a drive from one machine to another without the whole lot going kaboom.
I don't give a shit if anyone else uses linux, it works for me. Why should anyone who isn't making money from linux care about its market share?
Phil
I guess today is a passable day to die.
You're part right. Red Hat is playing the Microsoft here. IBM did create a monster in handing their OS over to RedHat. Now IBM needs a certification board (to back the service/support promises they need to make to stay in business). Unfortunately, their strategic partners refused to sign on to the LCC, so they're stuck with this private partnership.
OTOH, not that many of the actual contibuters (besides IBM and RH employees) to the linux platform will be running RH (let alone RHEL). As suppliers of the technology (and stubborn ones at that at that) they will exert a fair amount of pressure on RH to keep RHEL in line with the rest of the community.
Finally, based on IBM's pattern of behavior towards open standards in general, look for them to push this outward into a proper standards body (mind you, after it has already gelled).
..there's the gee whizz cool factor too. Some businesses are just too neat to go under easy, and will most likely always be around. IBM would have to major league screwup a dozen decisions in a row to go under, whereas MS will eventually start having it's lunch money taken away by open source. It's inevitable now. MS has peaked IMO.
MS makes the x box and some plastic disks with XP and an office app on them, whereas IBM makes ultra megasized liquid cooled nitro burning sooperdooper clusters with gigs of terrafloppies and other impressive sounding tech factoids. Which is cooler and more bitchin? Both companies got engineers, sales, PR and management, but which is really more impressive in it's overall historical corporate accomplishments? And which is more likely to keep on accomplishing serious new stuff that is most practical, long term? If you were an investor or analyst advising someone, where would you stash your cash given the choice of one or the other?
"Ok, so what the hell do we do about SO hell? "
admit it's 2004 almost 5, not 1994, that hard drives are huge now,and come redundant easily, getting a gig or more of ram is most affordable, cpus are hundreds of times faster than they used to be a decade ago, and that distros are starting to come on DVDs now so that they fit, and then realise the only solution to that SO hell and package management fooferall is to put all the files an app needs inside the app itself, so you can then stick the app wherever the heck you want to put it and it will "just work"?
Just a guess, I've been roundly criticised in the past for uttering that heresy because of upgrade issues..despite almost everyone actually concerned about immediate upgrades having high speed broadband now as well....