Yes, but forking isn't an issue because Apache pre-forks a number of "worker processes". So it should be true that a threaded Apache would give little advantage on many operating systems.
And I'd like to add that the fact that the VM worked fine from the very start, and Alan's choice to switch to it shows that Linus is capable of taking these decisions. Perhaps he shouldn't have been so second-guessed.
That's naive. The code might be doing nasty stuff without you ever knowing it. What if a Microsoft component sent al list of every file of your computer? You think they wouldn't do such a thing?
Such a thing couldn't be posible in a sandbox system, where the user can control exactly what happens without giving the keys of the house to anybody.
For those interested in downloading code from the NASA Classics Collection,
you should be aware that we are currently required to charge a fee for the
software. We are working with the people from NASA to try to "open" this
software to enable downloads without fees, at least for private,
non-commercial use.
So there's no public domain software.
(Argh.. I first posted this into the wrong article! =) )
For those interested in downloading code from the NASA Classics Collection,
you should be aware that we are currently required to charge a fee for the
software. We are working with the people from NASA to try to "open" this
software to enable downloads without fees, at least for private,
non-commercial use.
It makes sense to integrate an e-mail application with a web browser:
People want to read rich HTML e-mail.
People want to compose rich HTML, and the same composer is used in the web browser to create web -pages.
Now, it makes sense to integrate a a calendar application with an e-mail client, for obvious reasons.
You might say that what we need is a set of interfaces so *different* applications can coexist. But that is what Mozilla is! Everything is a component providing a set of functions (exported via XPCOM) to the rest of mozilla.
Try LBX (lbxproxy), it really helps. It's dxpc improved, turned into a standard and included in the core X specification. It was part of the X Consortium "Broadway" project that would put X into our browsers (!).
And what will IBM get for bribing people in Argentina's goverment to get the contract to computerize the national bank? Nothing, the US goverment covered up the IBM execs.
My experiencie implementing XML-RPC
on
ESR On XML-RPC
·
· Score: 3
This is my experience with XML-RPC:
I work for a company (Technisys)
which have created several years ago an RPC tool called "tmgen". This tool
is built as a layer on top of rpcgen, adding session cookie handling, SSL
support, a stateless server, handling of enumerated values with associated
long and short descriptions, and many other thing. It's in fact, an
application server built on top of RPC.
This baby have been running for many years in the most important banks
and credit cards companies here in Argentina (yes, you know the brands, but
I'm not sure I can tell you which ones =) ).
The "tmgen" tool reads a ".def" file that defines the
datatyes, and ".trn" files which have the code of the different
"transactions". Having read those files, it automatically generates the
server source (including the rpcgen input source).
I was asked to make it possible for the clients to be programmed in the
Java language. I evaluated several possibilities, one of them using a Java
client for RPC. This required us to go for a proprietary solution, besides,
being in control of both sides it looked silly to be tied to a protocol.
Another possibility would have been to modify tmgen to create an RMI server.
But the best was to create an XML server (IMO). I then evaluated SOAP and
XML-RPC. SOAP seemed very nice, but XML-RPC was *direct* mapping of the
semantics and types of our existing solution. The benefits of SOAP were a
drawback in this case, we just wanted to have strings, structs, ints and
floats.
So, now it's working. It takes a definition of the structs, the method
and which parameters they get, and it creates code (using the gnome-xml library (which I recommend). The
automatically generated code works as a standalone inetd webserver which
reads an XML-RPC query from the net, parses the query, loads it in the
generated C structures, run the "transaction", and creates a response from
the reply structures. The final result was that all those old C, RPC-only,
programs started to have an XML interface.
I added the Helma
RPC-XML client and voila, we had a Java client. So I must say that my
experience in this legacy system with XML-RPC was great.
Talking about new systems, I think that XML-RPC does the wrong thing, by
defining markup for the types instead of marking the semantic of the
data.
APT is just part of the thing. Debian has been great and smoothly updatable
for many years... before apt was created. I'll list the things (from Debian)
that RedHat needs to make this work:
The multi phase installation. Packages are unpacked and configured in
different steps.
Maintainer scripts. Debian has a rich and well defined set of scripts a
package can provide in order to leave things configured. They stop and start
services, check the system, update files, etc.
Strict policy. Debian packages are carefully made so as they work
together. There's a long policy document that specifies what should happen,
how and were, so: no suprises from that new package.
Virtual packages. A package must be able to depend on certain
"interface" or capability being present in the system, without having to
know which package provides it. E.g.: if a package wants to send a mail, it
will use the tradicional/usr/sbin/sendmail interface, and depend on a
package wich provides mail-transport-agent.
Drop file dependencies. They are dirty and evil, as everybody knows.
All packages involved should be of high quality. There's nothing you can
do with all this measures that will stop a broken packages from giving
trouble to users.
Several "subpolicies", so emacs, perl, sgml, etc. subsystems could work
together, trigering the registration, compilation, etc. of things when
packages are installed or removed.
A way for competing packages to be installed, this is made in Debian
with alternatives and diversions.
Config file handling. The system should never overwrite a config file.
In Debian, dpkg checks if the file has been modified since the package was
installed, and it will ask the user if the package wants to install a new
version. The user could then diff the files, edit, accept or reject the new
version.
A lot of work, perhaps several years... If these are the recognized goals of
a distribution, so we should drop everything and make Debian a standard..
=).
We *need* OpenDoc. We need a component model, and OpenDoc has all the features needed. IBM has already
promised
it will release OpenDoc as free software. We must email them and remind them of that promise!
..and of course Public Domain is approved as well, which is what we _real_ free software advocates have been encouraging for years.
We are where we are thanks to licenses like the GPL. PD and BSD licenses are great, but they don't contribute to advance free software.
PD is absolute freedom, so sbdy might think that is better "free software". And that's not how things work. Real freedom come from fair laws, freedom must be protected. A country with no laws has no freedom.
And I'm not a FS zealot.. =) I think these are objective facts. PD and BSD are centered in the availability of the software, GPL and the like are centered around free-software, that's how I see it.
It seems there's a litte misundestunding here. By approved, the author is saying that the license is real free-sfotware, with no hidden glitches. SCSL is not an approved OS license, for example. He didn't mean that Sun needs our approval for anything, just that the license conforms to what we regard as free software. And that's important, no matter how anti-RMS you might be, because it means software for everybody, with all the real practical benefits that truly free-software code gives to the people.
Slackware was once the obvious choice for a Linux distribution. But it has fallen from that plce, and now its only target are the old-timers who haven't switch to a more modern distribution.
People says that slackware is for power users... how come? It's not as secure as others, as its defaults are not as carefuly set as in other distros. Besides, as you need to get everything from a tgz, programs are not well integrated. It's not for the naive user.
Who is now the target of Slackware? Is it worth to continue developing it? Which are de mid-range objectives for the distro?
This will be moderated as a troll, but is a genuine doubt for me.. =)
There *is* a way to do that and it's called Debian. The apt-get utility manages all that and more. If you ask apt-get to install a new package, or a new version of an installed one, it will also download and install/upgrade the needed libraries.
This is not completelly related with the timeline, but... why now everything is a CGI? I can expect that from massive consumer products like, say, a Disney site... but people "in the community" should know that to properly build "the web" we need indexable and cacheable content.
Squid will not cache that timeline, so the 200 Linux users of a ISP will each download his own copy. Netscape won't probably cache it either, so you will need to download it again if you come back.
The pages will not be indexed, so if you make a query in Altavista with "+timeline +linux" you wont find the page.
I think there was a Slashdot article abaout this a short time ago, maybe we need some more until we learn.. =)
Note that you could still use a CGI and dont have all the problem I listed. Ask me how.. (and eeeevrybody will give you the same answers =) ).
Licenses are not little animals that should be protected =). And I think it would be great if everything were licensed under GPL, instead of the current situation.
Slashdot Mirror
Yes, but forking isn't an issue because Apache pre-forks a number of "worker processes". So it should be true that a threaded Apache would give little advantage on many operating systems.
Why? Axiom? Dogma?
And I'd like to add that the fact that the VM worked fine from the very start, and Alan's choice to switch to it shows that Linus is capable of taking these decisions. Perhaps he shouldn't have been so second-guessed.
That's naive. The code might be doing nasty stuff without you ever knowing it. What if a Microsoft component sent al list of every file of your computer? You think they wouldn't do such a thing?
Such a thing couldn't be posible in a sandbox system, where the user can control exactly what happens without giving the keys of the house to anybody.
So there's no public domain software.
It makes sense to integrate an e-mail application with a web browser:
Now, it makes sense to integrate a a calendar application with an e-mail client, for obvious reasons.
You might say that what we need is a set of interfaces so *different* applications can coexist. But that is what Mozilla is! Everything is a component providing a set of functions (exported via XPCOM) to the rest of mozilla.
Try LBX (lbxproxy), it really helps. It's dxpc improved, turned into a standard and included in the core X specification. It was part of the X Consortium "Broadway" project that would put X into our browsers (!).
I would think that you need an apt-able set of packages, designed to be fetched that way. And a package manager with features that RPM hasn't.
If you are curious about those thinfgs that makes APT not enough, check here.
Look! Other thing DB/2 hasn't! A ten letter name!
Sometimes I feel Slashdot needs a Idiotic moderation.
Well. I do put my Palm on my room's desktop.
And what will IBM get for bribing people in Argentina's goverment to get the contract to computerize the national bank? Nothing, the US goverment covered up the IBM execs.
This is my experience with XML-RPC:
I work for a company (Technisys) which have created several years ago an RPC tool called "tmgen". This tool is built as a layer on top of rpcgen, adding session cookie handling, SSL support, a stateless server, handling of enumerated values with associated long and short descriptions, and many other thing. It's in fact, an application server built on top of RPC.
This baby have been running for many years in the most important banks and credit cards companies here in Argentina (yes, you know the brands, but I'm not sure I can tell you which ones =) ).
The "tmgen" tool reads a ".def" file that defines the datatyes, and ".trn" files which have the code of the different "transactions". Having read those files, it automatically generates the server source (including the rpcgen input source).
I was asked to make it possible for the clients to be programmed in the Java language. I evaluated several possibilities, one of them using a Java client for RPC. This required us to go for a proprietary solution, besides, being in control of both sides it looked silly to be tied to a protocol. Another possibility would have been to modify tmgen to create an RMI server. But the best was to create an XML server (IMO). I then evaluated SOAP and XML-RPC. SOAP seemed very nice, but XML-RPC was *direct* mapping of the semantics and types of our existing solution. The benefits of SOAP were a drawback in this case, we just wanted to have strings, structs, ints and floats.
So, now it's working. It takes a definition of the structs, the method and which parameters they get, and it creates code (using the gnome-xml library (which I recommend). The automatically generated code works as a standalone inetd webserver which reads an XML-RPC query from the net, parses the query, loads it in the generated C structures, run the "transaction", and creates a response from the reply structures. The final result was that all those old C, RPC-only, programs started to have an XML interface.
I added the Helma RPC-XML client and voila, we had a Java client. So I must say that my experience in this legacy system with XML-RPC was great.
Talking about new systems, I think that XML-RPC does the wrong thing, by defining markup for the types instead of marking the semantic of the data.
I hope I haven't bored anyone with my experience.
- The multi phase installation. Packages are unpacked and configured in
different steps.
- Maintainer scripts. Debian has a rich and well defined set of scripts a
package can provide in order to leave things configured. They stop and start
services, check the system, update files, etc.
- Strict policy. Debian packages are carefully made so as they work
together. There's a long policy document that specifies what should happen,
how and were, so: no suprises from that new package.
- Virtual packages. A package must be able to depend on certain
"interface" or capability being present in the system, without having to
know which package provides it. E.g.: if a package wants to send a mail, it
will use the tradicional
/usr/sbin/sendmail interface, and depend on a
package wich provides mail-transport-agent.
- Drop file dependencies. They are dirty and evil, as everybody knows.
- All packages involved should be of high quality. There's nothing you can
do with all this measures that will stop a broken packages from giving
trouble to users.
- Several "subpolicies", so emacs, perl, sgml, etc. subsystems could work
together, trigering the registration, compilation, etc. of things when
packages are installed or removed.
- A way for competing packages to be installed, this is made in Debian
with alternatives and diversions.
- Config file handling. The system should never overwrite a config file.
In Debian, dpkg checks if the file has been modified since the package was
installed, and it will ask the user if the package wants to install a new
version. The user could then diff the files, edit, accept or reject the new
version.
A lot of work, perhaps several years... If these are the recognized goals of a distribution, so we should drop everything and make Debian a standard.. =).We *need* OpenDoc. We need a component model, and OpenDoc has all the features needed. IBM has already promised it will release OpenDoc as free software. We must email them and remind them of that promise!
And that's what we are talking about! The Open Source definition is taken from the DFSG. It's the samt thing word for word. =)
We are where we are thanks to licenses like the GPL. PD and BSD licenses are great, but they don't contribute to advance free software.
PD is absolute freedom, so sbdy might think that is better "free software". And that's not how things work. Real freedom come from fair laws, freedom must be protected. A country with no laws has no freedom.
And I'm not a FS zealot.. =) I think these are objective facts. PD and BSD are centered in the availability of the software, GPL and the like are centered around free-software, that's how I see it.
It seems there's a litte misundestunding here. By approved, the author is saying that the license is real free-sfotware, with no hidden glitches. SCSL is not an approved OS license, for example. He didn't mean that Sun needs our approval for anything, just that the license conforms to what we regard as free software. And that's important, no matter how anti-RMS you might be, because it means software for everybody, with all the real practical benefits that truly free-software code gives to the people.
Slackware was once the obvious choice for a Linux distribution. But it has fallen from that plce, and now its only target are the old-timers who haven't switch to a more modern distribution.
People says that slackware is for power users... how come? It's not as secure as others, as its defaults are not as carefuly set as in other distros. Besides, as you need to get everything from a tgz, programs are not well integrated. It's not for the naive user.
Who is now the target of Slackware? Is it worth to continue developing it? Which are de mid-range objectives for the distro?
This will be moderated as a troll, but is a genuine doubt for me.. =)
There *is* a way to do that and it's called Debian. The apt-get utility manages all that and more. If you ask apt-get to install a new package, or a new version of an installed one, it will also download and install/upgrade the needed libraries.
But you can script thing in order to generate static files only once. e.g. just using a makefile and m4.
Anyway, to have the pages cached you need:
Squid will not cache that timeline, so the 200 Linux users of a ISP will each download his own copy. Netscape won't probably cache it either, so you will need to download it again if you come back.
The pages will not be indexed, so if you make a query in Altavista with "+timeline +linux" you wont find the page.
I think there was a Slashdot article abaout this a short time ago, maybe we need some more until we learn.. =)
Note that you could still use a CGI and dont have all the problem I listed. Ask me how.. (and eeeevrybody will give you the same answers =) ).
Licenses are not little animals that should be protected =). And I think it would be great if everything were licensed under GPL, instead of the current situation.