MS has no need of emulators like Wine. MS, I believe, actually owns MainSoft, and in any case, has allowed them to port Win32, COM MSXML, and a boatload of other junk to SysV Unix and Linux.
If MS doesn't release applications under Linux, it's because they don't want to.
SAPDB is the open source incarnation of SAP's Adabas-derived database. It's a wonderful package, with much potential.
This is an example of a company-sponsored effort,all forms of development outside SAP appears to be discouraged. Source code is released in tarballs without advanced warning. There is no CVS access.
There seem to be several issues involved:
1. SAP employees want to define 100% of the feature set. They see it as their internal project which they release for external use "as is"
2. Weak internal documentation, in German
3. Weird issues related to source code shared between the GPL SAPDB, and other, closed source, SAP projects. The developers refuse to explain how these work, or document them.
No, it's you who are mistaken about the GPL and how it has functioned in creating a viable space into which companies supporting Linux--and indeed, as Caldera itself proves, all of Unix--could expand.
Moreover, to be quite honest, I'd say that Caldera has focussed on packaging Linux with proprietary value-added software almost from the beginning (e.g., NDS, NCP, Wabi, Wordperfect 7, Netscape Fasttrack Server, others). Now they've bought SCO and the Unix trademark. Blaming the GPL licensing of _other_ software distributed with Linux, or, (are they insane?) Linux itself for the failure of Caldera to aggregate a sustainable Linux service business seems misguided and maybe dishonest.
Just as it's self-evident that lots of software infrastructure is not going to be free any time soon, it should be equally clear that _which_ packages "should" or "can't" be developed under a particular license just isn't obvious.
Sorry Caldera (and Brett Glass, and Microsoft), but you're just going to have to live with that. Whining isn't going to make your free competitors go away.
If Redhat were the only mainstream distribution viewed as credible, Linux probably would not survive serious strategic mistakes, such as a major release which cannot run Oracle8i.
Instead, the diversity of Linux platforms enables workarounds, with minimal fuss. In our experience, SUSE Linux 7.0 has been an excellent server OS.
Interesting that the trade commentators continue to mention Caldera as a likely survivor of these distro consolidations. Their series of moves aligning Linux with DOS, Netware, SCO, and the like has always seemed doubtful. It don't see it deployed much in companies, FWIW.
But, I have deployed 8.2.x extensively, and I run Bind as user "named" or "dns" as a matter of course.
If Bind9 can't be run securely on Linux--and I don't think LinuxThreads are materially different in 2.4--then Bind9 may just be where I get off the train.
How does TransGaming propose to compensate all the developers whose years of inglorious foundation work made their work possible?
"Bribe us to release our new source" models are really a shareware transition right back to closed source private code ownership.
Virtually No Coverage of Dynamic Routing
on
Linux Routers
·
· Score: 4
I liked the book, and certainly felt it would be very helpful to folks doing the most common 85% or so of network device setup tasks.
On the other hand, I felt the title of the book constituted a promise that it would include good coverage of dynamic routing protocols like OSPF, RIP2, and others--all of which are available in strong Linux implementations.
This book covers the entire concept of dynamic routing in about 4 pages, in section 8.4--and the coverage is completely inadequate. There isn't usable information on setting up ANY dynamic routing protocol--OSPF isn't even in the index of the book. (It's on mention is in the glossary.)
The big problem for SCO here is that even if SCO UnixWare were a good product, it could never deliver the value of Open Source Linux.
Unfortunately, SCO UnixWare is NOT a good product. I should know--I've worked with two revisions of SCO UnixWare, and Univell UnixWare itself since version 1.
Between 1994 and 1996, I worked for a systems integrator--mostly programming for Linux--and during that time, found myself working on two SCO UnixWare deals. Both were implementation and support nightmares--thanks to both the poor quality of the SCO product, and the equally poor quality of its (very expensive) product support.
1. An accouting firm in Detroit was migrating to UnixWare from pure AT&T 386 SysV (Oracle). Due to undocumented bugs in the SCO PCI implementation, UnixWare 2.11 wouldn't even INSTALL on 5 out of 6 PCI motherboards we tried. Meanwhile, the SCO hardware compatibility list was nearly two years out of date, and SCO reps refused to endorse any vendor's motherboards for use with the product. Once installed, we spent three weeks debugging problems with UnixWare's buggy ethernet drivers--which a reliable source told us were in some obscene manner derived from Netware DOS binaries.
2. Later, someone in our office sold UnixWare as a Novell MHS mail gateway. Too bad the PERL scripts AND the Novell integration were so buggy that a SCO tech support person (whom we paid much money) confided the product was basically unsuable. We had to rewrite portions of the mail gateway ourselves, and never solved intermittent connection problems between UnixWare and Novell.
The role models of the Linux community--Linus, Larry Wall, Alan Cox, many others--have it, at least one-on-one.
But it is well known that there is something about a lists and BBSes like Slashdot that promotes putdowns, grandstanding, and discourtesy. A look at Kernel Traffic (mostly reprints of the kernel list) shows that Linus and Alan Cox not too irregularly flame each other brutally, producing hurts that later must be smoothed over.
It is high-schoolish--just wrong--to assume that this is a model for collaboration, even if it works most of the time.
Everyone on Slashdot and who counts him/herself as a Linux community member should once and for all give up the notion that it is funny or cool to be a smartass, and instead strive to be reasonable and friendly as much as possible.
Why? Because that is an appropriate way to treat others, and becuase that really is how you make friends and influence people--something I think most of us really do want to achieve.
I, for one, am quite uncomfortable with the rather cavalier approach Corel appears to be taking to proprietarization of Linux.
The intent of this press release appears to be to see if Linux users object to the notion of a completely proprietary desktop, owned by Corel, as the means to "bring Linux to the desktop"--as if the efforts of KDE and GNOME--the KDE effort, in particular, being very far advanced and impressive--haven't been absolutely instrumental in the current convergence on Linux among vendors and end-users alike.
I would expect Microsoft to follow suit in short order with their own, Win32 desktop for Linux--so Linux users can finally enjoy the benefits of a "standard" and "professional" user interface. If we want to go that way, I think we might as well buy NT--and I have no such intention.
I was similarly troubled by the tone of a previous Corel press release, in which a Corel executive stated they think Linux gives Corel the opportunity to "dominate the UNIX market."
Corel appears to be offering a great asset to the Linux community with one hand--its office applications, WINE assistance--and threatening that community with the other. Linux users benefit from commercial products, they don't benefit from domination.
I think what we should get from Mr. Love's statement is, surely, an indication that there is now strain within what was once a multi-vendor agreement to support something called the LSB.
I confess to not following these developments closely enough. Could someone knowledgeable perhaps post an objective summary of the current state of affairs?
In general, I think that posters here have expressed fair-minded skepticism regarding the need for--and viability of--an overly restrictive LSB. However, I think it fair to say that Linux distributions are as compatible as they are, due to a desire to remain so.
There is real danger that some Linux distributor (eg, Microsoft, Corel?) might emerge with an agenda to embrace and extend the system in proprietary ways. (Corel statements that they intend to develop proprietary UI "standards", and that they see an opportunity to "dominate the UNIX market", show cause for concern.) However, the danger would lie not in the attempt to do so, but in the willingness of ISVs and consumers to accept this tactic. I am indeed beginning to hear--from consumers and IT people--language like, "we're looking to Redhat to provide...". This is bad news for the community, because even though I doubt Redhat really has any intention of "consolidating the Linux market," the Redhat of 5 years from now could find itself the "defacto standard"--which would indeed greatly stifle the innovation and competitiveness Linux represents today.
Ultimately, the Linux community is going to have to be very savvy about this kind of move, and even about general trends, and develop an ability to mobilize opinion against proprietarization attempts.
NB: Applications are NOT required to choose static linkage, if they don't like the library layout of a given system--and many large UNIX apps, such as Oracle, already do not. An application can set LD_LIBRARY_PATH, and use libraries shipped with the application. For GPL'd libraries, this means making source available--however, this is much less a deal than ISVs might imagine. Savvy companies like IBM and HP will have no difficulty with it.
Slashdot Mirror
I'm astonished no one has mentioned this.
MS has no need of emulators like Wine. MS, I believe, actually owns MainSoft, and in any case, has allowed them to port Win32, COM MSXML, and a boatload of other junk to SysV Unix and Linux.
If MS doesn't release applications under Linux, it's because they don't want to.
Eben Moglen--great choice.
:)
He has been extraordinary on this issue, I think. (BP pretty good, too
SAPDB is the open source incarnation of SAP's Adabas-derived database. It's a wonderful package, with much potential.
This is an example of a company-sponsored effort,all forms of development outside SAP appears to be discouraged. Source code is released in tarballs without advanced warning. There is no CVS access.
There seem to be several issues involved:
1. SAP employees want to define 100% of the feature set. They see it as their internal project which they release for external use "as is"
2. Weak internal documentation, in German
3. Weird issues related to source code shared between the GPL SAPDB, and other, closed source, SAP projects. The developers refuse to explain how these work, or document them.
So I guess you're a librarian.
Cut back a little on the puffery and spin, and I might be more persuaded.
Why are all the replies to this moderated down? Some of them are interesting, and relevant.
Moreover, to be quite honest, I'd say that Caldera has focussed on packaging Linux with proprietary value-added software almost from the beginning (e.g., NDS, NCP, Wabi, Wordperfect 7, Netscape Fasttrack Server, others). Now they've bought SCO and the Unix trademark. Blaming the GPL licensing of _other_ software distributed with Linux, or, (are they insane?) Linux itself for the failure of Caldera to aggregate a sustainable Linux service business seems misguided and maybe dishonest.
Just as it's self-evident that lots of software infrastructure is not going to be free any time soon, it should be equally clear that _which_ packages "should" or "can't" be developed under a particular license just isn't obvious.
Sorry Caldera (and Brett Glass, and Microsoft), but you're just going to have to live with that. Whining isn't going to make your free competitors go away.
Never work? Who knows. I try to avoid predicting the ultimate future of human cultural development.
If Redhat were the only mainstream distribution viewed as credible, Linux probably would not survive serious strategic mistakes, such as a major release which cannot run Oracle8i.
Instead, the diversity of Linux platforms enables workarounds, with minimal fuss. In our experience, SUSE Linux 7.0 has been an excellent server OS.
Interesting that the trade commentators continue to mention Caldera as a likely survivor of these distro consolidations. Their series of moves aligning Linux with DOS, Netware, SCO, and the like has always seemed doubtful. It don't see it deployed much in companies, FWIW.
Given that Berlin is theoretical, does it have currency in academic circles?
Is it in any way a pratical effort?
I haven't worked yet with Bind9.
But, I have deployed 8.2.x extensively, and I run Bind as user "named" or "dns" as a matter of course.
If Bind9 can't be run securely on Linux--and I don't think LinuxThreads are materially different in 2.4--then Bind9 may just be where I get off the train.
"Bribe us to release our new source" models are really a shareware transition right back to closed source private code ownership.
I liked the book, and certainly felt it would be very helpful to folks doing the most common 85% or so of network device setup tasks.
On the other hand, I felt the title of the book constituted a promise that it would include good coverage of dynamic routing protocols like OSPF, RIP2, and others--all of which are available in strong Linux implementations.
This book covers the entire concept of dynamic routing in about 4 pages, in section 8.4--and the coverage is completely inadequate. There isn't usable information on setting up ANY dynamic routing protocol--OSPF isn't even in the index of the book. (It's on mention is in the glossary.)
This is a valuable post. Someone should moderate it up.
The big problem for SCO here is that even if SCO UnixWare were a good product, it could never deliver the value of Open Source Linux.
Unfortunately, SCO UnixWare is NOT a good product. I should know--I've worked with two revisions of SCO UnixWare, and Univell UnixWare itself since version 1.
Between 1994 and 1996, I worked for a systems integrator--mostly programming for Linux--and during that time, found myself working on two SCO UnixWare deals. Both were implementation and support nightmares--thanks to both the poor quality of the SCO product, and the equally poor quality of its (very expensive) product support.
1. An accouting firm in Detroit was migrating to UnixWare from pure AT&T 386 SysV (Oracle). Due to undocumented bugs in the SCO PCI implementation, UnixWare 2.11 wouldn't even INSTALL on 5 out of 6 PCI motherboards we tried. Meanwhile, the SCO hardware compatibility list was nearly two years out of date, and SCO reps refused to endorse any vendor's motherboards for use with the product. Once installed, we spent three weeks debugging problems with UnixWare's buggy ethernet drivers--which a reliable source told us were in some obscene manner derived from Netware DOS binaries.
2. Later, someone in our office sold UnixWare as a Novell MHS mail gateway. Too bad the PERL scripts AND the Novell integration were so buggy that a SCO tech support person (whom we paid much money) confided the product was basically unsuable. We had to rewrite portions of the mail gateway ourselves, and never solved intermittent connection problems between UnixWare and Novell.
I do not feel sorry for this company.
The role models of the Linux community--Linus, Larry Wall, Alan Cox, many others--have it, at least one-on-one.
But it is well known that there is something about a lists and BBSes like Slashdot that promotes putdowns, grandstanding, and discourtesy. A look at Kernel Traffic (mostly reprints of the kernel list) shows that Linus and Alan Cox not too irregularly flame each other brutally, producing hurts that later must be smoothed over.
It is high-schoolish--just wrong--to assume that this is a model for collaboration, even if it works most of the time.
Everyone on Slashdot and who counts him/herself as a Linux community member should once and for all give up the notion that it is funny or cool to be a smartass, and instead strive to be reasonable and friendly as much as possible.
Why? Because that is an appropriate way to treat others, and becuase that really is how you make friends and influence people--something I think most of us really do want to achieve.
cavalier approach Corel appears to be taking to proprietarization of Linux.
The intent of this press release appears to be to see if Linux users object to the notion of a completely proprietary desktop, owned by Corel, as the means to "bring Linux to the desktop"--as if the efforts of KDE and GNOME--the KDE effort, in particular, being very far advanced and impressive--haven't been absolutely instrumental in the current convergence on Linux among vendors and end-users alike.
I would expect Microsoft to follow suit in short order with their own, Win32 desktop for Linux--so Linux users can finally enjoy the benefits of a "standard" and "professional" user interface. If we want to go that way, I think we might as well buy NT--and I have no such intention.
I was similarly troubled by the tone of a previous Corel press release, in which a Corel executive stated they think Linux gives Corel the opportunity to "dominate the UNIX market."
Corel appears to be offering a great asset to the Linux community with one hand--its office applications, WINE assistance--and threatening that community with the other. Linux users benefit from commercial products, they don't benefit from domination.
is now strain within what was once a multi-vendor agreement to support something called
the LSB.
I confess to not following these developments closely enough. Could someone knowledgeable
perhaps post an objective summary of the current state of affairs?
In general, I think that posters here have expressed fair-minded skepticism regarding the
need for--and viability of--an overly restrictive LSB. However, I think it fair to say
that Linux distributions are as compatible as they are, due to a desire to remain so.
There is real danger that some Linux distributor (eg, Microsoft, Corel?) might emerge with an agenda
to embrace and extend the system in proprietary ways. (Corel statements that they intend to develop proprietary UI "standards", and that they see an opportunity to "dominate the UNIX market", show cause for concern.) However, the danger would lie not in
the attempt to do so, but in the willingness of ISVs and consumers to accept this tactic.
I am indeed beginning to hear--from consumers and IT people--language like, "we're looking
to Redhat to provide...". This is bad news for the community, because even though I doubt
Redhat really has any intention of "consolidating the Linux market," the Redhat of 5 years
from now could find itself the "defacto standard"--which would indeed greatly stifle the
innovation and competitiveness Linux represents today.
Ultimately, the Linux community is going to have to be very savvy about this kind of move,
and even about general trends, and develop an ability to mobilize opinion against
proprietarization attempts.
NB: Applications are NOT required to choose static linkage, if they don't like the
library layout of a given system--and many large UNIX apps, such as Oracle, already do not.
An application can set LD_LIBRARY_PATH, and use libraries shipped with the application.
For GPL'd libraries, this means making source available--however, this is much less a deal
than ISVs might imagine. Savvy companies like IBM and HP will have no difficulty with
it.
The facts are in. Talk to your CS prof, and get the momentum to see this tripe rebutted in the pages of the original journal.