XFS has ACLs, unlike ReiserFS and ext3 (last time I checked).
Also, XFS comes with xfsdump and xfsrestore, which can back up and restore the ACLs. I believe it is the only ACL-enabled file system for Linux which has such utilities (unless you count AFS).
So for a production environment where you want ACLs, XFS is the only choice right now. And it seems likely to remain so for a while.
Also, Samba 2.2 has built-in integration with XFS ACLs, making Linux+XFS+Samba a very interesting option for replacing NT file servers.
Sorry, but no; your mind itself is just an algorithm.
More verbosely: The original file is the input to your mind. The resulting decompressor+file is the output of your mind. This output is just a compressed version of the input produced by the algorithm in your brain (and your books, and any experts you consult, etc).
So the whole process, from beginning to end, is just a compression algorithm. I cannot describe the algorithm, exactly, but simple counting shows that it is unlikely that it will successfully compress a randomly chosen string, no matter how long the string is.
The principle you are espousing is the same one which has driven
Curl's design from the beginning. We call this design principle the
"gentle slope".
The idea is that an ordinary text document is a valid Curl program.
You can do simple markup using a syntax about as complex as HTML. If
you want a more interactive page, you can do it by learning a little
more Curl; you do not need to suddenly learn a completely different
technology like Javascript. As you learn more Curl, you can create
more complex dynamic documents. Eventually, perhaps before you know it,
you have gone beyond documents and are writing full-blown
object-oriented applications. The author has been led down the gentle
slope and has become a programmer.
That was the idea, anyway. The "gentle slope" concept permeated
every design discussion we had, and we always considered it the
principal architectural goal. It was not always an easy goal, and
how well we succeeded remains to be seen. But we did try.
The gentle slope also extends all the way down into the
heart of the runtime. All of the components in the Curl
system (including the layout engine, the rendering engine, the
debugger, and so on) are themselves written in Curl, so you can invoke
them directly when you need them. For example, you do not need to
learn some disparate "document object model" to create complex layouts
on the fly; you can just invoke the object oriented interface which is
already present in the guts of the system. The full benefits of this
tightly integrated environment are hard to describe, but they do become
obvious if you spend some time playing with it. Or so we hope.
By the way, this integrated "universal" environment, with its easily
composed and reused pieces, is squarely in the tradition of the
great Lisp machines. Exactly how Curl is like Lisp, and unlike Lisp, and why,
is a topic for another time...
Yes, it is a browser plug-in. It started as a standalone
application, but we figured end users would not be interested if it
did not run in their browsers.
We still use the standalone version internally to build Curl,
because most of the Curl client is written in Curl itself.
We have had a Linux version internally from the very beginning, but
we are not comfortable making it a supported product yet (sound
familiar?). About 1/3 of our developers have Linux machines on their
desktops, and nothing gets committed to the source tree unless it
passes all tests on both Linux and Windows. So releasing a Linux
version would not be too hard.
The only reason we monitor what you view is to allow us to charge
commercial content providers. As much as possible, the information is
collected and used only in summary.
We are well aware that end users do not like being
monitored, and we are well aware that they do not like to pay metered
rates. We have designed our revenue model and associated metering
mechanism with this in mind. Apparently, we need to make our privacy
policy more clear.
Our present revenue model is directed at two groups:
Non-commercial sites (no charge)
Large commercial sites (charge by volume of executed content)
At the moment, we do not have a good answer for small commercial
sites. We do not yet have enough sales staff to
support a huge number of small customers anyway.
Our intent has always been to obtain revenue from people who are
making money off of Curl technology. Doing this directly based on
their profits is very difficult in practice. So for now, we are going
with this metering model.
But if you are not making money off of Curl, we have
no desire to bother you in any way. In fact, we want to encourage
you, because we want Curl to spread. Hence we have no charge for
non-commercial use, and we provide lots of free resources for
developers.
Our business folks were faced with the interesting problem of how
to take this technology and make it into a commercial product. They
thought about it for a (very) long time, and this is what they came up
with. Can you think of a better idea?
Curl started as a research project at MIT around five years ago, which may predate cURL (I am not sure). Regardless, by the time we were aware of cURL, we already had too much invested in our name. Sorry for the confusion.
Actually, one of Curl's original design choices was that a simple
text document would also be a valid Curl program. (We backed away
from this slightly by requiring a "herald" at the top. This was
necessary to have a sane configuration and versioning plan.) To
access Curl's features, whether for markup, scripting, or full-blown
OO programming, you insert commands delimited by curly braces.
Another design choice was that we would ship source code over the
wire (i.e., more like HTML than like Java). We also backed away from
this slightly; you can now optionally trasmit preprocessed Curl for
faster JIT compilation and some amount of obfuscation. But we still
expect most Curl code to be flung over the network as source, which we
are hoping will help it catch on like HTML did and for the same
reasons.
Anyway, you certainly can edit Curl code using a simple text
editor. As someone else noticed, we do distribute an Emacs Curl mode
(which I wrote).
I hope you will give us another chance. The Web site was written
by our marketing department, and right now it is directed more at
investors and customers than at developers. As a result, many of
Curl's strengths from a developer's perspective have been somewhat
buried.
A Curl version of the Web site is in the works. Until some people
actually have the client, there is not much point.
It is true that JSP and Curl can be complementary technologies
(server-side production of a client-side applet). But in this case,
the parallel version of our site will be designed to illustrate the
advantages of moving most of the computation to the client.
Slashdot Mirror
XFS has ACLs, unlike ReiserFS and ext3 (last time I checked).
Also, XFS comes with xfsdump and xfsrestore, which can back up and restore the ACLs. I believe it is the only ACL-enabled file system for Linux which has such utilities (unless you count AFS).
So for a production environment where you want ACLs, XFS is the only choice right now. And it seems likely to remain so for a while.
Also, Samba 2.2 has built-in integration with XFS ACLs, making Linux+XFS+Samba a very interesting option for replacing NT file servers.
Sorry, but no; your mind itself is just an algorithm.
More verbosely: The original file is the input to your mind. The resulting decompressor+file is the output of your mind. This output is just a compressed version of the input produced by the algorithm in your brain (and your books, and any experts you consult, etc).
So the whole process, from beginning to end, is just a compression algorithm. I cannot describe the algorithm, exactly, but simple counting shows that it is unlikely that it will successfully compress a randomly chosen string, no matter how long the string is.
The principle you are espousing is the same one which has driven Curl's design from the beginning. We call this design principle the "gentle slope".
The idea is that an ordinary text document is a valid Curl program. You can do simple markup using a syntax about as complex as HTML. If you want a more interactive page, you can do it by learning a little more Curl; you do not need to suddenly learn a completely different technology like Javascript. As you learn more Curl, you can create more complex dynamic documents. Eventually, perhaps before you know it, you have gone beyond documents and are writing full-blown object-oriented applications. The author has been led down the gentle slope and has become a programmer.
That was the idea, anyway. The "gentle slope" concept permeated every design discussion we had, and we always considered it the principal architectural goal. It was not always an easy goal, and how well we succeeded remains to be seen. But we did try.
The gentle slope also extends all the way down into the heart of the runtime. All of the components in the Curl system (including the layout engine, the rendering engine, the debugger, and so on) are themselves written in Curl, so you can invoke them directly when you need them. For example, you do not need to learn some disparate "document object model" to create complex layouts on the fly; you can just invoke the object oriented interface which is already present in the guts of the system. The full benefits of this tightly integrated environment are hard to describe, but they do become obvious if you spend some time playing with it. Or so we hope.
By the way, this integrated "universal" environment, with its easily composed and reused pieces, is squarely in the tradition of the great Lisp machines. Exactly how Curl is like Lisp, and unlike Lisp, and why, is a topic for another time...
Yes, it is a browser plug-in. It started as a standalone application, but we figured end users would not be interested if it did not run in their browsers.
We still use the standalone version internally to build Curl, because most of the Curl client is written in Curl itself.
We have had a Linux version internally from the very beginning, but we are not comfortable making it a supported product yet (sound familiar?). About 1/3 of our developers have Linux machines on their desktops, and nothing gets committed to the source tree unless it passes all tests on both Linux and Windows. So releasing a Linux version would not be too hard.
The Mac version will be... tricky. :-)
The only reason we monitor what you view is to allow us to charge commercial content providers. As much as possible, the information is collected and used only in summary.
We are well aware that end users do not like being monitored, and we are well aware that they do not like to pay metered rates. We have designed our revenue model and associated metering mechanism with this in mind. Apparently, we need to make our privacy policy more clear.
Our present revenue model is directed at two groups:
At the moment, we do not have a good answer for small commercial sites. We do not yet have enough sales staff to support a huge number of small customers anyway.
Our intent has always been to obtain revenue from people who are making money off of Curl technology. Doing this directly based on their profits is very difficult in practice. So for now, we are going with this metering model.
But if you are not making money off of Curl, we have no desire to bother you in any way. In fact, we want to encourage you, because we want Curl to spread. Hence we have no charge for non-commercial use, and we provide lots of free resources for developers.
Our business folks were faced with the interesting problem of how to take this technology and make it into a commercial product. They thought about it for a (very) long time, and this is what they came up with. Can you think of a better idea?
Curl started as a research project at MIT around five years ago, which may predate cURL (I am not sure). Regardless, by the time we were aware of cURL, we already had too much invested in our name. Sorry for the confusion.
Actually, one of Curl's original design choices was that a simple text document would also be a valid Curl program. (We backed away from this slightly by requiring a "herald" at the top. This was necessary to have a sane configuration and versioning plan.) To access Curl's features, whether for markup, scripting, or full-blown OO programming, you insert commands delimited by curly braces.
Another design choice was that we would ship source code over the wire (i.e., more like HTML than like Java). We also backed away from this slightly; you can now optionally trasmit preprocessed Curl for faster JIT compilation and some amount of obfuscation. But we still expect most Curl code to be flung over the network as source, which we are hoping will help it catch on like HTML did and for the same reasons.
Anyway, you certainly can edit Curl code using a simple text editor. As someone else noticed, we do distribute an Emacs Curl mode (which I wrote).
I hope you will give us another chance. The Web site was written by our marketing department, and right now it is directed more at investors and customers than at developers. As a result, many of Curl's strengths from a developer's perspective have been somewhat buried.
A Curl version of the Web site is in the works. Until some people actually have the client, there is not much point.
It is true that JSP and Curl can be complementary technologies (server-side production of a client-side applet). But in this case, the parallel version of our site will be designed to illustrate the advantages of moving most of the computation to the client.