> Cygwin can be used freely for making free, opensource products, Qt cannot. What > are you getting at?
I didn't say the models were the same - I said they were similar. I just mean that Cygnus makes money from closed licenses on software which they also openly license, that's all. The details do differ.
> Thanks to cygnus, BTW, for making the hell of being stuck in Win NT all day a little less. You guys are sweet.
Photoshop for Linux would help (porting in one direction).
Gimp for Windows will help less (porting in the other).
A few good points, but I still think it's nice for Troll Tech to pay those guys to work on free software. I bought the book you mention, BTW. And the $1000+ price tag is nothing for a commercial developer with a serious application to port to windows (which I am not, BTW). The total porting costs to such developers might be tens or hundreds of thousands of dollars worth of company time per project.
BTW, you *do* realize that cygwin uses a very similar model to Qt, don't you? Cygwin is a GPLed (*not* LGPLed) library - fine for free software. But Cygnus will also sell you a license to link it with proprietary code. If you fail to purchase such a license, then your app must be free software too.
I was one of the people who petitioned Troll Tech to put Qt under the GPL. I would have preferred that, but the QPL is not really that bad, when you get down to it.
And the non-free status of the Windows port is all for the better.
Wake *UP* people - they are doing us a favour! They are funding development which helps the cause of Linux, BSD and friends, and they are doing it at the expense of the Windows market *only*.
This solution is not only acceptable to me - it's damned near ideal. If the windows port was open-source, then it would retard the cause of free software in two ways:
1. It would deprive Troll Tech of revenues which allow them to *pay* engineers to work on the *free* X11 port.
2. It would allow Windows users to use cool, free software that normally runs on *nix platforms - thus reducing their incentive to switch. We want to drive the application availability situation to the advantage of Linux, etc. people!
I've thought of this approach too. It should be very fast once you're done - maybe faster than any other way. But it seems to me the going will be very slow. C/C++ is much more work to write than Perl, PHP and the like. And you'll need to learn alot about the Apache module API. I looked at this API in some detail and realized how complicated it might get.
You could of course start it out as a module - forgetting the CGI version. If you're leaking memory during development, keep 'MaxRequestsPerChild' at a very low value - 10 or maybe 1 even. Then increase it to 100 or whatever when your leaks are under control.
Can you say 'interoperability'?
on
911 Calls Linux
·
· Score: 1
I don't buy a word of what you say! I, too, work in a environment where NT is mandatory for some things.
But we are managing to integrate Linux into the mix with stuff like Samba, VNC or Xservers (Exceed, or similar), internet protocols and stuff like wrapper scripts. We integrate applications across platforms and distribute data and control transparently.
Yours is one of the most *dangerous* posts I have seen on Slashdot in a long time. The absurd, damaging opinion I often hear regarding system management is that you're better off with one system/vendor/whatever for *everything*. 'From top to bottom', 'from soup to nuts'.
This is poison, this is damnation, this is oblivion. This is the way to end up with only one vendor left, with no alternatives, and very little incentive for them to really perform.
*Try* to integrate alternatives. Try *hard*. Many of us have done it, as this article should show. And if we can keep up the trend, everyone who comes after will benefit.
I can tell you about the DCOM wire protocol spec, but please make the effort to set up a slashdot account and log in - i.e. don't post as an Anonymous Coward.
If I could have gotten an e-mail address, I would have e-mailed you your answer directly! People here on slashdot *want* to help each other - please let us help you by facilitating the paths of communication.
DCOM uses so-called Microsoft RPC to connect COM objects on separate machines. Microsoft RPC is a derivative of DCE RPC - the RPC standard which is part of the Distributed Computing Environment.
DCE was created by the Open Software Federation (OSF) in the late 80's to compete with Sun's ONC (Open Network Computing) environment. Sun's simple and ubiquitous RPC implementation is the lynch-pin technology in ONC. DCE is a more complex alternative. It is not open source, but I believe all of the protocols and interfaces are openly documented.
Microsoft RPC uses the same wire protocol as DCE RPC - I believe it may still be exactly the same, but I'm not sure. They did change the C API, but I believe Microsoft RPC clients can still call DCE RPC servers, and vice versa.
So the answer to your question is rather simple. If you want the wire protocol spec for DCOM, it is the one for Microsoft RPC, which is the same as the one for DCE RPC.
The Open Group, the descendant of the OSF, is the current keeper of the DCE specs, and now also the COM and DCOM specs, BTW.
This is what "resource files" are for. Though sometimes maligned, they can be useful.
If you *insist* on hardcoding, you could have the snippets of output stashed in static array(s) of strings allocated in a separate source file, then put that source file under a BSD or MIT -like license. Then link this into the GPLed program.
Problem solved. The data could be statically linked into the same binary, and yet still be completely unaffected by the GPL or *any* other license the rest of the program might be under.
It's about time someone chimed in with this pivotal information.
If you ask me it's criminally misleading for ZD to quote "hits per second" and not quote bandwidth too. People have lost all sense of just how gigantic 1000 hits/second is. 20 or so at this size will saturate a T1!
Red Hat, SuSE, Caldera, Slack and the others are all *cool*. But Debian represents the best future for all operating systems development. A vast, collective, unbiased effort to build an operating system foundation. This foundation then becomes the optimum starting point for a company or other entity to build a custom solution upon. Debian is the one distribution which most closely mirrors the development model of the Linux kernel itself.
Either Debian, or an effort like it, will eclipse Red Hat, not to mention Microsoft, and become the great fuel source for the network computing fire. Look for NCs, server appliances, and other 'preconfigured' solutions built upon it. Not to mention plenty of packaged software. And look for other kernels than Linux as well.
It definitely seems to me that if you want to be able to radically shape or reshape a distribution, you start off with Debian.
Since Slashdot is running a heavy-duty Linux webserver on an SMP machine, the httpd.conf, etc. from this site might make for an interesting comparison.
I'm sorry that you have such a weak grasp of economics, but participation of multi-nationals in poorer economies it *the* primary engine of growth in those economies. Without fail, it is the unstable political and social circumstances in some poor countries, which frightens off multi-nationals, which reinforces their poverty. The post which you responding to was *absolutely* on the mark. And your criticisms are way off base.
*All* of the dynamo economies in developing countries were primed by very heavy investment from the developed world, often through multi-nationals.
I thought so. So all distros should put GNU/Linux on the box/CD, and it should be the full, official name. But we can all call it Linux in casual conversation. And reporters can call it Linux to RMS's face and he should take it more gently:-/
...for OO, GUI and Client/Server stuff in Tcl/Tk. If you need to do any of the previous, then read his stuff!
He created the [Incr Tcl] and derivative extensions. And in addition to the above book, he contributed a couple of good chapters to O'Reilly's excellent "Tcl/Tk Tools" - a compendium of Tcl/Tk extensions - which Harrison edited.
I do believe that both Perl/Tk and Python/Tkinter still use a Tcl interpreter to drive the Tk GUI. The Perl or Python interp is interfaced to the Tcl Interp. This is why these approaches are no more responsive (even slower?) from a UI standpoint, even though Perl and Python are generally faster languages than Tcl.
I believe that someone was working on a Tcl-less version of Tk, but that's not the one that everyone uses.
Isn't using templates in code to be compiled by gcc still a little questionable? I mean, I heard that they worked a lot better now with egcs, but I get the impression they must still be slow (even flaky?). I'm not a C++ guru, so I could be wrong.
Anyway, I figure that may be one reason that Troll Tech never worried too much about template support.
No Adobe required. Postscript may have started out as very proprietary, but it's getting rather close to an open standard now. Postscript was and is a smart idea - well thought out. An effort to beef up Ghostscript further, and an big push for PS as *the* standard seems like a much cleaner and more direct solution to me.
Will someone *please* get CmdrTaco a Debian 2.1 CD
on
Pre-Beta Slackware 4.0
·
· Score: 1
He's mentioned it a few times now...
Been running it myself since a couple days after the release:-)
While trying to figure out how the creation of the 'net is like the discovery of fire, it finally clicked: That might explain all those darned flame wars that we keep having;-)
BTW, you must be crazy be crazy if you think I have time this morning to read that whole silly article. Let's get back to some real computer news. (Sorry John;-)
There's nothing wrong with RedHat. But lot's of people use other distros and the world is *definitely* better off for this diversity.
Don't switch from Debian! As a fellow Debian user, I think that it's *very* possible that Debian could be the most popular distro in the not too distant future. It has greater international reach and it's more suitable for specially tailored applications. It provides a better foundation for network appliance-style computing, which may be the wave of the future.
I can envision a future where the most common computers are cheap, little, netwinder-esque things in homes and businesses. A company wishing to sell boxes like these wants a highly configurable distro like Debian to work with - and would probably then add lots of customizations. RedHat's easy install will buy their engineers nothing. RedHat is only easiest on random PCs, not carefully preconfigured and engineered systems.
Slashdot Mirror
> Cygwin can be used freely for making free, opensource products, Qt cannot. What
> are you getting at?
I didn't say the models were the same - I said they were similar. I just mean that Cygnus makes money from closed licenses on software which they also openly license, that's all. The details do differ.
> Thanks to cygnus, BTW, for making the hell of being stuck in Win NT all day a little less. You guys are sweet.
Amen, brother. I love cygwin too.
Photoshop for Linux would help (porting in one direction).
Gimp for Windows will help less (porting in the other).
A few good points, but I still think it's nice for Troll Tech to pay those guys to work on free software. I bought the book you mention, BTW. And the $1000+ price tag is nothing for a commercial developer with a serious application to port to windows (which I am not, BTW). The total porting costs to such developers might be tens or hundreds of thousands of dollars worth of company time per project.
BTW, you *do* realize that cygwin uses a very similar model to Qt, don't you? Cygwin is a GPLed (*not* LGPLed) library - fine for free software. But Cygnus will also sell you a license to link it with proprietary code. If you fail to purchase such a license, then your app must be free software too.
I was one of the people who petitioned Troll Tech to put Qt under the GPL. I would have preferred that, but the QPL is not really that bad, when you get down to it.
And the non-free status of the Windows port is all for the better.
Wake *UP* people - they are doing us a favour! They are funding development which helps the cause of Linux, BSD and friends, and they are doing it at the expense of the Windows market *only*.
This solution is not only acceptable to me - it's damned near ideal. If the windows port was open-source, then it would retard the cause of free software in two ways:
1. It would deprive Troll Tech of revenues which allow them to *pay* engineers to work on the *free* X11 port.
2. It would allow Windows users to use cool, free software that normally runs on *nix platforms - thus reducing their incentive to switch. We want to drive the application availability situation to the advantage of Linux, etc. people!
I've thought of this approach too. It should be very fast once you're done - maybe faster than any other way. But it seems to me the going will be very slow. C/C++ is much more work to write than Perl, PHP and the like. And you'll need to learn alot about the Apache module API. I looked at this API in some detail and realized how complicated it might get.
You could of course start it out as a module - forgetting the CGI version. If you're leaking memory during development, keep 'MaxRequestsPerChild' at a very low value - 10 or maybe 1 even. Then increase it to 100 or whatever when your leaks are under control.
I don't buy a word of what you say! I, too, work in a environment where NT is mandatory for some things.
But we are managing to integrate Linux into the mix with stuff like Samba, VNC or Xservers (Exceed, or similar), internet protocols and stuff like wrapper scripts. We integrate applications across platforms and distribute data and control transparently.
Yours is one of the most *dangerous* posts I have seen on Slashdot in a long time. The absurd, damaging opinion I often hear regarding system management is that you're better off with one system/vendor/whatever for *everything*. 'From top to bottom', 'from soup to nuts'.
This is poison, this is damnation, this is oblivion. This is the way to end up with only one vendor left, with no alternatives, and very little incentive for them to really perform.
*Try* to integrate alternatives. Try *hard*. Many of us have done it, as this article should show. And if we can keep up the trend, everyone who comes after will benefit.
I can tell you about the DCOM wire protocol spec, but please make the effort to set up a slashdot account and log in - i.e. don't post as an Anonymous Coward.
If I could have gotten an e-mail address, I would have e-mailed you your answer directly! People here on slashdot *want* to help each other - please let us help you by facilitating the paths of communication.
DCOM uses so-called Microsoft RPC to connect COM objects on separate machines. Microsoft RPC is a derivative of DCE RPC - the RPC standard which is part of the Distributed Computing Environment.
DCE was created by the Open Software Federation (OSF) in the late 80's to compete with Sun's ONC (Open Network Computing) environment. Sun's simple and ubiquitous RPC implementation is the lynch-pin technology in ONC. DCE is a more complex alternative. It is not open source, but I believe all of the protocols and interfaces are openly documented.
Microsoft RPC uses the same wire protocol as DCE RPC - I believe it may still be exactly the same, but I'm not sure. They did change the C API, but I believe Microsoft RPC clients can still call DCE RPC servers, and vice versa.
So the answer to your question is rather simple. If you want the wire protocol spec for DCOM, it is the one for Microsoft RPC, which is the same as the one for DCE RPC.
The Open Group, the descendant of the OSF, is the current keeper of the DCE specs, and now also the COM and DCOM specs, BTW.
Have a look at:
http://www.opengroup.org/dce
and your journey will begin. Good luck!
This seems easy to solve - without any exemptions to the GPL.
It would seem you either need to read in, or link in source files which fall under a more liberal, but GPL-compatible license.
See "resource files or static arrays" posted below.
Dammit, you beat me to it :-)
Absolutely right - *don't* hardcode it.
This is what "resource files" are for. Though sometimes maligned, they can be useful.
If you *insist* on hardcoding, you could have the snippets of output stashed in static array(s) of strings allocated in a separate source file, then put that source file under a BSD or MIT -like license. Then link this into the GPLed program.
Problem solved. The data could be statically linked into the same binary, and yet still be completely unaffected by the GPL or *any* other license the rest of the program might be under.
It's about time someone chimed in with this pivotal information.
If you ask me it's criminally misleading for ZD to quote "hits per second" and not quote bandwidth too. People have lost all sense of just how gigantic 1000 hits/second is. 20 or so at this size will saturate a T1!
Red Hat, SuSE, Caldera, Slack and the others are all *cool*. But Debian represents the best future for all operating systems development. A vast, collective, unbiased effort to build an operating system foundation. This foundation then becomes the optimum starting point for a company or other entity to build a custom solution upon. Debian is the one distribution which most closely mirrors the development model of the Linux kernel itself.
Either Debian, or an effort like it, will eclipse Red Hat, not to mention Microsoft, and become the great fuel source for the network computing fire. Look for NCs, server appliances, and other 'preconfigured' solutions built upon it. Not to mention plenty of packaged software. And look for other kernels than Linux as well.
It definitely seems to me that if you want to be able to radically shape or reshape a distribution, you start off with Debian.
Since Slashdot is running a heavy-duty Linux webserver on an SMP machine, the httpd.conf, etc. from this site might make for an interesting comparison.
MaxRequestsPerChild 10000 indeed!
10000!!! The default on my Debian system is 30.
I am not an Apache guru, but this dubious parameter setting may be part of their fiendish systematic detuning of their Linux system.
By setting this value so high, they exacerbate memory leaks. This might be why their performance collapsed after a while.
I'm sorry that you have such a weak grasp of economics, but participation of multi-nationals in poorer economies it *the* primary engine of growth in those economies. Without fail, it is the unstable political and social circumstances in some poor countries, which frightens off multi-nationals, which reinforces their poverty. The post which you responding to was *absolutely* on the mark. And your criticisms are way off base.
*All* of the dynamo economies in developing countries were primed by very heavy investment from the developed world, often through multi-nationals.
Ever called Windows NT just 'NT'?
:-/
Ever called Unix System V Release 4 just 'SVR4'?
Ever called a Chevrolet Camaro Z28 just 'a Z28'?
I thought so. So all distros should put GNU/Linux on the box/CD, and it should be the full, official name. But we can all call it Linux in casual conversation. And reporters can call it Linux to RMS's face and he should take it more gently
Don't you know nuthin' :-)
...for OO, GUI and Client/Server stuff in Tcl/Tk. If you need to do any of the previous, then read his stuff!
He created the [Incr Tcl] and derivative extensions. And in addition to the above book, he contributed a couple of good chapters to O'Reilly's excellent "Tcl/Tk Tools" - a compendium of Tcl/Tk extensions - which Harrison edited.
I have both but only use each for reference - i.e haven't read them cover to cover.
They're both good books. Welch's is the expansive, complete reference.
Harrison/McLennan is more like the hot-insider-tips kind of book. It points out a lot of cool, but inobvious, things.
I do believe that both Perl/Tk and Python/Tkinter still use a Tcl interpreter to drive the Tk GUI. The Perl or Python interp is interfaced to the Tcl Interp. This is why these approaches are no more responsive (even slower?) from a UI standpoint, even though Perl and Python are generally faster languages than Tcl.
I believe that someone was working on a Tcl-less version of Tk, but that's not the one that everyone uses.
Someone correct me if I'm wrong...
Isn't using templates in code to be compiled by gcc still a little questionable? I mean, I heard that they worked a lot better now with egcs, but I get the impression they must still be slow (even flaky?). I'm not a C++ guru, so I could be wrong.
Anyway, I figure that may be one reason that Troll Tech never worried too much about template support.
No Adobe required. Postscript may have started out as very proprietary, but it's getting rather close to an open standard now. Postscript was and is a smart idea - well thought out. An effort to beef up Ghostscript further, and an big push for PS as *the* standard seems like a much cleaner and more direct solution to me.
He's mentioned it a few times now...
:-)
Been running it myself since a couple days after the release
While trying to figure out how the creation of the 'net is like the discovery of fire, it finally clicked: That might explain all those darned flame wars that we keep having ;-)
;-)
BTW, you must be crazy be crazy if you think I have time this morning to read that whole silly article. Let's get back to some real computer news. (Sorry John
Things that I like ...
:-)
That Richard Stallman doesn't like:
KDE
O'Reilly Books
Tom Christiansen
That Tom Christiansen doesn't like:
GNU/Linux
GPLed Documentation
Richard Stallman
But I can like all of these things, and so can you
Mike Greaves
There's nothing wrong with RedHat. But lot's of people use other distros and the world is *definitely* better off for this diversity.
Don't switch from Debian! As a fellow Debian user, I think that it's *very* possible that Debian could be the most popular distro in the not too distant future. It has greater international reach and it's more suitable for specially tailored applications. It provides a better foundation for network appliance-style computing, which may be the wave of the future.
I can envision a future where the most common computers are cheap, little, netwinder-esque things in homes and businesses. A company wishing to sell boxes like these wants a highly configurable distro like Debian to work with - and would probably then add lots of customizations. RedHat's easy install will buy their engineers nothing. RedHat is only easiest on random PCs, not carefully preconfigured and engineered systems.
Mike Greaves
If you do, you'll sound like a jackass. Even though he doesn't.
Don't be dumpin on somebody's cutie-pie.