If it were only about compile-time dynamic linking, I would probably agree with you. However it's not.
What's more important is what happens at runtime. While it's true that for example the GPL says it only restricts distribution it really draws its validity from runtime linking. It is this combining (indeed very tight combining in case of runtime linking, into a single binary in a single address space) of two different works that forms a derivative work, at least as much as static linking creates a derivative work (which I hope can be stipulated). But, and this is the important thing, even the creation, not mere distribution, of derivative works is an exclusive right of the copyright holder. Hence, even if compile-time dynamic linking wouldn't be infringing as is, the resulting binary cannot be used in any legal way - indeed it is designed to be used in an illegal way - and that's not something the courts are going to allow.
But "derivative" cannot be defined in the license, that's precisely the problem. If it isn't derivative, the license saying so cannot make it. It's a sort of "nobody knows for sure" situation until some court makes it very clear.
The mere act of linking (or otherwise calling a function by its signature) is not sufficient to create derivation.
I believe it is. There are border cases but I believe this very clearly creates a derivative work.
And one thing worth remembering is that licenses really have no say in what is derived and what is not. It's a matter for the courts (and law).
If A is not a derived work of B, the license of B just cannot restrict what you do with A. It's just like saying "The Windows kernel is a derivative work of gzip just because I say so" - it's not, and it's not for you to decide. Unfortunately what constitutes a derivative work in case of software is not as clear-cut as most people would hope.
Of course some developer can state in his license that he doesn't consider some use of his code as constituting a derivative work; or quite equivalently (but wrongly) stating that it is not a derivative work. While such a statement (the later one) might be technically incorrect, it prevents the licensor from changing his mind about that (this is called estoppel).
Funnily enough, that bug report doesn't seem to talk about licensing issues at all (but it does talk about trust issues). Please go RTFBR you claim to have filed:-)
The job of a religious practitioner is to succeed in his or her practice, and it is through this that they may help others - any activity that projects one's religious beliefs outward is very risky, and needs to be undertaken with great seriousness, and probably not on a forum as public as slashdot.
I disagree with your logic. Or I misinterpret you.
Basically what you seem (to me) to be saying is that being open and actively telling about your faith is morally wrong independent of a) what you believe and b) whether what you believe is true or not.
However, consider this. Christians generally believe that the only way of being saved (going to Heaven) is through faith on Jesus Christ. Also they believe that if you are not saved, you will suffer after your death eternally in a lake of fire. They (we) really believe it, it's not just some principle that affects how we live in this life.
Now, let's assume for the sake of this counterargument that what Christians believe is correct (which fits in (b)). I could talk about moral values in Bible here, but I believe we should be able to stipulate that Bible teaches that selflessness and helping others is good.
Now, it's true that very many people don't want to be helped. If it was really so that nobody would listen to us Christians AND one can be certain that nobody is going to be saved anymore, it perhaps could be argued that active evangelization would be an unnecessary nuisance and therefore probably wrong.
However, think about it this way. If you really really do believe that the majority of people around you are going to suffer in an eternal fire, and that it could be possible to save at least some of them, then is it morally right to not try? Even considering that, what, 99% of people who don't want to hear anything about it, I'd maintain that the remaining 1% or even a single person that can be saved makes it more than worth it. After all, this life is only a finite piece of time, very short compared to eternity.:-)
That's how we Christians see it. Hope this explains it to you satisfactorily. I don't expect it to make it appear any less annoying to you, but perhaps it helps you understand our behavior a little more.
I agree. I did such an informal test myself some time ago, and reiser4 won easily (but lost my test data at least back then - I'll wait for a while before trying it again).
I agree. My choice of words could have been better (and I do consider POV-Ray utterly non-free).
I think I added the qualification "technically" because I thought it might make some people think twice before replying "its source is available, so it's open source, never mind the commonly accepted definition". Now that I think about it, it probably doesn't even serve that purpose very well:)
The parent post does make some sense, though I'd agree it's a flamebait in such a terse form without elaboration.
From Open Source point of view, POV-Ray is problematic. Technically it is not Open Source; for example, commercial distribution is not allowed. One of the most misunderstood and most important strengths of OSS is the ability to use in any kind of settings, including commercial, military, etc. For example Apache would never have become popular if its license forbade using it for commercial purposes.
Also your right to modify it and distribute your modifications (this includes using parts of it in a new open source program) are severely limited.
It's a function from six dimensions to three (the color space). And XYZ can represent every color visible to the human eye, using just three values.
The base vectors in the 3D color space are determined by the three types of receptors in our eyes. The fact that there are three types of receptors, each of which gives a scalar (1D vector) value to the brain, should make it more than obvious that the color space is at most 3D. It could be less than 3D if all the receptors were vectors in the same plane, but it happens to be that the color space indeed is truly 3D - not less, but neither more.
While it's true that you cannot strip down a 6D vector to a 3D and get it back, that's not the issue here. The very nature of human eyes reduces the visible color space to 3D, and adding 3, 6 or 100 vectors to the color space simply makes no difference at all.
See, you can get a different spectrum when you add more components. The spectrum is continuous, hence no amount of vectors is enough to give an exact representation of it. But what human sees is not the spectrum, but a mapping from it to a 3D space, which can amply be represented with just three components.
The issue here is six vectors in a three-directional space, which is the entire color space human can perceive (hence three of the six vectors are actually redundant, or rather would be if we permitted negative values. However we don't, why the three extra vectors are actually useful even in the 3D space). Think about it. Take any six vectors from a real 3D space and represent a point using them. Now, you can go to 3 vectors without any loss of precision, ie. you still have exactly the same point. Of course there are infinitely many ways to transform it back to those six vectors, but it doesn't matter because you get to exactly the same point in the 3D space no matter how you traverse to it. This is really similar to the issue here, the color space is 3D too because there are only three types of receptors in the human eye.
We have to separate the two very different sources of loss here:
1. Loss due to the target color space not being able to represent the color in the source color space; for example RGB cannot represent all colors visible to the human eye (without having negative components);
2. Precision loss in the conversion.
Now these two are very different beasts, and #2 can be avoided to an arbitratry precision if you for some reason wanted to. Actually with some cleverness the conversion could be avoided altogether until the XYZ signal is in the viewing device where it can be converted to the nearest matching color you can display to an arbitrary precision (unless of course it's an XYZ display in which case you don't need to convert at all:-). On the other hand, the RGB color space is fundamentally not able to represent all colors visible to the human eye with positive amounts of R, G and B - this is #1 type loss.
Now, to your actual claim:
While the shade of color reproduced with such a conversion might be close, it won't get the color back all of the way and will lose some information, and information that will be noticed by a good eye.
Ah, but you forget that human eyes are actually discrete too. There's a limited number of receptors for each "primary color", and the intensity of that component as interpreted by the brain is determined by (number of receptors activated)/(total number of receptors). Thus with enough precision, it is possible to convert even with discrete signals from a more restrictive color space to a less restrictive one without any loss you could perceive.
Legal reasons: The problem isn't with distribution itself. The likely problem is that to bundle/integrate SFU with the OS the way MS WANTS to "embrace" it would require "extending" some of that GNU software. Microsoft is never content with merely putting the software on the CD--it wants to fuse it with the OS a la IE. THAT is where the GPL would get in the way, because MS depends heavily on keeping its extensions to open standards and systems proprietary--something the GPL forbids.
Merely putting the software on the CD might be a violation for Microsoft (and for Microsoft only) if it is linked to non-GPL Microsoft code (system libs, like the standard c library). GPL permits linking the application to non-GPL components that come with the platform it runs on, but it's not at all obvious that you can use this for your advantage if you're the platform vendor too.
Its source is available, but open source it's not. Of course there are always some people who try to twist language enough to claim that "open source" == "source available", but then if you wanted to be understood you'd say "source available". Open source did never, and will never, mean simply "source code available for viewing under some arbitrary conditions which may or may not include paying a billion dollars".
Except that Crafty is far from being open source. From the license:
No part of this program may be reproduced in any form or by any means, for other than your personal use, without the express written permission of the author. This program may not be used in whole, nor in part, to enter any computer chess competition without written permission from the author.
Any software distributed under the GPL is open source, but not all open source software is distributed under the GPL. Other common licenses include X11, BSD, MIT and LGPL.
I don't mean it's not GPL - I mean it's not open source. It's also not closed source.
The term "open source" has never had the meaning "software with source code available". Prior to being used to describe software that meets certain openness criteria, it simply did not exist. Instead you would have said something along the lines of, well, "software with source code available".
Of course now that it has a commonly accepted definition, some people would like to distort it by claiming that it simply means "with source code available". I'm glad they have so far been quite unsuccessful at that:-)
It's really like trying to sell weights made of paper under the term "paper weight". While perhaps technically correct (and I'd say even more so than using "open source" to mean "source available"!), it's likely to confuse people and, essentially, paper weight will _never_ mean "a weight made of paper".
It's still very restrictive: It for example forbids distributing ANY derived code, or even renaming anything. Clause 4.5 even effectively prevents including it in any (IMO) sane static (i.e. CD or such) distribution planned to be current for more than two years.
In fact it seems to me even more non-free than things like Shared Source:(
POV-Ray is not open source. The license forbids, among others, commercial distribution. In fact now that I read the 3.6 license, it seems to forbid distribution, PERIOD.
This seems to be an interesting contrast to this comment where someone (apparently a POV-Ray developer?) discusses plans to release POV-Ray under an open source license and explains why this is not currently possible:
"we can't reach many of the people who contributed the original code under the old license, so we don't have the right to just switch the license. We'll have to rewrite some pretty big chunks of code before we can think about a more open license. That (the rewrite) is slated to happen for the next major release."
I just investigated the major players a few weeks ago for my own purposes, although I tested the (still-in-development) reiser4 instead of reiser3.
To me, the ability to both shrink and expand the filesystems is also essential. In brief, ext3 can be expanded and shrunk offline. XFS and JFS can only be expanded. ReiserFS supports both shrinking and expanding. IIRC, ReiserFS can be expanded, but not shrunk, online. XFS can probably only be expanded offline. I think JFS can only be expanded online (which I think is a bit weird, but OK:-).
On my computer (with enough CPU power for it to probably not be a bottleneck - Athlon XP 2600+), these are some timings for operations like extracting a huge.tar file (IIRC ~1 GB) containing enormous amounts of small files on a newly mkfs'd 20G partition, copying the extracted tree, running du -c on the tree and rm -rf:ing the tree. The partition was always unmounted and remounted between operations to invalidate caches, with the mount option noatime on all filesystems and data=ordered on ext3.
(this looks terrible because I couldn't get even the ecode tag to work nicely, so it's a hack)
From this it seems to me that overall reiser4 would be the clear winner when CPU is not the bottleneck. Unfortunately reiser4 didn't seem very stable although it was claimed "it's usable but still not recommended for production environments". Even during my tests I got repeatedly data loss, and after typically a couple of days of heavy reiser4 use top started to indicate that almost 100% of the CPU time was being spent in a syscall (and some processes became unkillable), a probable sign of a reiser4 operation in a syscall ending in an infinite loop (it didn't use disk in that loop though). I could not reproduce this kind of problems with any of the other filesystems.
I think reiser4 is definitely a promising filesystem with interesting concepts for systems with lots of CPU power, however as this is not the first time I've had problems with reiserfs (even production versions), it's going to be a while after it becomes stable after I'll be ready to even test it again and consider adopting it.
Yes. Python doesn't (currently) do any kind of JIT compiling and is therefore purely an interpreted language and won't be affected by this change. To explain a bit further:
Basically we can divide programming languages (and environments) into compiled languages and interpreted languages. Compiled languages are usually fast but in many ways unsafe and the resulting programs are harder to observe. Interpreted languages are slow but observing and debugging the program is easy. Also a compiled program can only be run on a single architecture without recompiling while interpreted programs can be run on any architecture for which an interpreter exists.
Now there's a special class of languages that are compiled to bytecode which is closer to actual machine language than the source code yet independent from architecture. The resulting bytecode is run in a virtual machine (VM), which still has to interpret or compile it.
Often interpreting the bytecode is even slower than interpreting the original language. However, compiling the code and then running it only once is usually even slower than interpreting. The solution is to compile the code just in time (JIT) when it has possibly already been interpreted a few times and it seems likely it will be executed again and again. This way only the speed-critical parts of the program will ever be compiled, resulting in performance (arguably) close to compiled languages without tying the program to a single architecture.
Now, just as for any other compiler, from the JIT compiler's point of view both the bytecode and the compiled, machine-executable code is pure data. So the problem arises when the VM suddenly wants to transfer control from its interpreter code to the JIT-compiled code. The operating system has taken care of marking all the VM code as "OK to execute" when the program was started, but now no-one, unless the VM, has told the operating system that the new code is OK to execute. Therefore the OS cannot distinguish it from a case where a malicious user has fed machine code to a program as data and used a flaw in the program to jump into it, which is the way most common exploits work.
As for Python, I wouldn't actually classify it into bytecode languages, at least not yet. AFAIK the "bytecode" that Python scripts can be compiled into is more like a parse tree of the program than machine code, and the Python interpreter still purely interprets it. No generated machine code is executed at any point in time and hence the above scenario doesn't apply.
In fact, source code is really just a very precise specification of what the computer has to do. It's so precise that it can be translated into an executable form automatically.:-)
Yes, that's true. The problem with it is that it cannot easily be split into abstract parts and be thus reasoned about. You can reason about bits and bytes, but that doesn't get you very far.
For example, we could specify (a silly example:-) that f() is a function that always returns a prime number. This can be a very precise specification of the requirements of what f() must do - it must return a prime number. It's about abstraction, we don't specify anything we don't want to specify at this level.
Then we have a lower level specification that satisfies the higher level specification - for example, we specify that the function f() always returns a number from the set {2,3,5}. Then we prove that this satisfies the higher level specification, ie. f() really returns and it returns only prime numbers.
Then we get closer to the real implementation - we specify that f() always returns 3. It's easy to prove that this satisfies the former specification.
Now we write code for a function that always returns 3 and prove that it matches the specification. And suddenly we have an implementation of a function that always returns prime numbers. Other implementations might be possible.
Ok, this is too trivial an example. But a similar thing could be made for, say, a sorting function. We can specify that a function returns its parameters sorted. This way we have split the problem space into smaller parts: We need to prove that the given function works as specified, and then we can use the proved properties as axioms (ie. that the list is sorted and that it contains the same elements as the original list) in the higher level specification.
Slashdot Mirror
If it were only about compile-time dynamic linking, I would probably agree with you. However it's not.
What's more important is what happens at runtime. While it's true that for example the GPL says it only restricts distribution it really draws its validity from runtime linking. It is this combining (indeed very tight combining in case of runtime linking, into a single binary in a single address space) of two different works that forms a derivative work, at least as much as static linking creates a derivative work (which I hope can be stipulated). But, and this is the important thing, even the creation, not mere distribution, of derivative works is an exclusive right of the copyright holder. Hence, even if compile-time dynamic linking wouldn't be infringing as is, the resulting binary cannot be used in any legal way - indeed it is designed to be used in an illegal way - and that's not something the courts are going to allow.
But "derivative" cannot be defined in the license, that's precisely the problem. If it isn't derivative, the license saying so cannot make it. It's a sort of "nobody knows for sure" situation until some court makes it very clear.
The mere act of linking (or otherwise calling a function by its signature) is not sufficient to create derivation.
I believe it is. There are border cases but I believe this very clearly creates a derivative work.
And one thing worth remembering is that licenses really have no say in what is derived and what is not. It's a matter for the courts (and law).
If A is not a derived work of B, the license of B just cannot restrict what you do with A. It's just like saying "The Windows kernel is a derivative work of gzip just because I say so" - it's not, and it's not for you to decide. Unfortunately what constitutes a derivative work in case of software is not as clear-cut as most people would hope.
Of course some developer can state in his license that he doesn't consider some use of his code as constituting a derivative work; or quite equivalently (but wrongly) stating that it is not a derivative work. While such a statement (the later one) might be technically incorrect, it prevents the licensor from changing his mind about that (this is called estoppel).
Funnily enough, that bug report doesn't seem to talk about licensing issues at all (but it does talk about trust issues). Please go RTFBR you claim to have filed :-)
The job of a religious practitioner is to succeed in his or her practice, and it is through this that they may help others - any activity that projects one's religious beliefs outward is very risky, and needs to be undertaken with great seriousness, and probably not on a forum as public as slashdot.
:-)
I disagree with your logic. Or I misinterpret you.
Basically what you seem (to me) to be saying is that being open and actively telling about your faith is morally wrong independent of a) what you believe and b) whether what you believe is true or not.
However, consider this. Christians generally believe that the only way of being saved (going to Heaven) is through faith on Jesus Christ. Also they believe that if you are not saved, you will suffer after your death eternally in a lake of fire. They (we) really believe it, it's not just some principle that affects how we live in this life.
Now, let's assume for the sake of this counterargument that what Christians believe is correct (which fits in (b)). I could talk about moral values in Bible here, but I believe we should be able to stipulate that Bible teaches that selflessness and helping others is good.
Now, it's true that very many people don't want to be helped. If it was really so that nobody would listen to us Christians AND one can be certain that nobody is going to be saved anymore, it perhaps could be argued that active evangelization would be an unnecessary nuisance and therefore probably wrong.
However, think about it this way. If you really really do believe that the majority of people around you are going to suffer in an eternal fire, and that it could be possible to save at least some of them, then is it morally right to not try? Even considering that, what, 99% of people who don't want to hear anything about it, I'd maintain that the remaining 1% or even a single person that can be saved makes it more than worth it. After all, this life is only a finite piece of time, very short compared to eternity.
That's how we Christians see it. Hope this explains it to you satisfactorily. I don't expect it to make it appear any less annoying to you, but perhaps it helps you understand our behavior a little more.
I agree. I did such an informal test myself some time ago, and reiser4 won easily (but lost my test data at least back then - I'll wait for a while before trying it again).
See this comment for the raw data from the test.
I agree. My choice of words could have been better (and I do consider POV-Ray utterly non-free).
:)
I think I added the qualification "technically" because I thought it might make some people think twice before replying "its source is available, so it's open source, never mind the commonly accepted definition". Now that I think about it, it probably doesn't even serve that purpose very well
The parent post does make some sense, though I'd agree it's a flamebait in such a terse form without elaboration.
From Open Source point of view, POV-Ray is problematic. Technically it is not Open Source; for example, commercial distribution is not allowed. One of the most misunderstood and most important strengths of OSS is the ability to use in any kind of settings, including commercial, military, etc. For example Apache would never have become popular if its license forbade using it for commercial purposes.
Also your right to modify it and distribute your modifications (this includes using parts of it in a new open source program) are severely limited.
It's a function from six dimensions to three (the color space). And XYZ can represent every color visible to the human eye, using just three values.
The base vectors in the 3D color space are determined by the three types of receptors in our eyes. The fact that there are three types of receptors, each of which gives a scalar (1D vector) value to the brain, should make it more than obvious that the color space is at most 3D. It could be less than 3D if all the receptors were vectors in the same plane, but it happens to be that the color space indeed is truly 3D - not less, but neither more.
While it's true that you cannot strip down a 6D vector to a 3D and get it back, that's not the issue here. The very nature of human eyes reduces the visible color space to 3D, and adding 3, 6 or 100 vectors to the color space simply makes no difference at all.
See, you can get a different spectrum when you add more components. The spectrum is continuous, hence no amount of vectors is enough to give an exact representation of it. But what human sees is not the spectrum, but a mapping from it to a 3D space, which can amply be represented with just three components.
The issue here is six vectors in a three-directional space, which is the entire color space human can perceive (hence three of the six vectors are actually redundant, or rather would be if we permitted negative values. However we don't, why the three extra vectors are actually useful even in the 3D space). Think about it. Take any six vectors from a real 3D space and represent a point using them. Now, you can go to 3 vectors without any loss of precision, ie. you still have exactly the same point. Of course there are infinitely many ways to transform it back to those six vectors, but it doesn't matter because you get to exactly the same point in the 3D space no matter how you traverse to it. This is really similar to the issue here, the color space is 3D too because there are only three types of receptors in the human eye.
We have to separate the two very different sources of loss here:
:-). On the other hand, the RGB color space is fundamentally not able to represent all colors visible to the human eye with positive amounts of R, G and B - this is #1 type loss.
1. Loss due to the target color space not being able to represent the color in the source color space; for example RGB cannot represent all colors visible to the human eye (without having negative components);
2. Precision loss in the conversion.
Now these two are very different beasts, and #2 can be avoided to an arbitratry precision if you for some reason wanted to. Actually with some cleverness the conversion could be avoided altogether until the XYZ signal is in the viewing device where it can be converted to the nearest matching color you can display to an arbitrary precision (unless of course it's an XYZ display in which case you don't need to convert at all
Now, to your actual claim:
While the shade of color reproduced with such a conversion might be close, it won't get the color back all of the way and will lose some information, and information that will be noticed by a good eye.
Ah, but you forget that human eyes are actually discrete too. There's a limited number of receptors for each "primary color", and the intensity of that component as interpreted by the brain is determined by (number of receptors activated)/(total number of receptors). Thus with enough precision, it is possible to convert even with discrete signals from a more restrictive color space to a less restrictive one without any loss you could perceive.
Legal reasons: The problem isn't with distribution itself. The likely problem is that to bundle/integrate SFU with the OS the way MS WANTS to "embrace" it would require "extending" some of that GNU software. Microsoft is never content with merely putting the software on the CD--it wants to fuse it with the OS a la IE. THAT is where the GPL would get in the way, because MS depends heavily on keeping its extensions to open standards and systems proprietary--something the GPL forbids.
Merely putting the software on the CD might be a violation for Microsoft (and for Microsoft only) if it is linked to non-GPL Microsoft code (system libs, like the standard c library). GPL permits linking the application to non-GPL components that come with the platform it runs on, but it's not at all obvious that you can use this for your advantage if you're the platform vendor too.
Simple.
It fails at least OSD #1, #3, #4 and #6.
Its source is available, but open source it's not. Of course there are always some people who try to twist language enough to claim that "open source" == "source available", but then if you wanted to be understood you'd say "source available". Open source did never, and will never, mean simply "source code available for viewing under some arbitrary conditions which may or may not include paying a billion dollars".
Except that Crafty is far from being open source. From the license:
No part of this program may be reproduced in any form or by any means, for other than your personal use, without the express written permission of the author. This program may not be used in whole, nor in part, to enter any computer chess competition without written permission from the author.
Also I must add that GPL != open source.
Any software distributed under the GPL is open source, but not all open source software is distributed under the GPL. Other common licenses include X11, BSD, MIT and LGPL.
I don't mean it's not GPL - I mean it's not open source. It's also not closed source.
:-)
The term "open source" has never had the meaning "software with source code available". Prior to being used to describe software that meets certain openness criteria, it simply did not exist. Instead you would have said something along the lines of, well, "software with source code available".
Of course now that it has a commonly accepted definition, some people would like to distort it by claiming that it simply means "with source code available". I'm glad they have so far been quite unsuccessful at that
It's really like trying to sell weights made of paper under the term "paper weight". While perhaps technically correct (and I'd say even more so than using "open source" to mean "source available"!), it's likely to confuse people and, essentially, paper weight will _never_ mean "a weight made of paper".
Thanks, I missed that.
:(
It's still very restrictive: It for example forbids distributing ANY derived code, or even renaming anything. Clause 4.5 even effectively prevents including it in any (IMO) sane static (i.e. CD or such) distribution planned to be current for more than two years.
In fact it seems to me even more non-free than things like Shared Source
POV-Ray is not open source according to the generally recognized definition of open source.
Satisfied?
POV-Ray is not open source. The license forbids, among others, commercial distribution. In fact now that I read the 3.6 license, it seems to forbid distribution, PERIOD.
This seems to be an interesting contrast to this comment where someone (apparently a POV-Ray developer?) discusses plans to release POV-Ray under an open source license and explains why this is not currently possible:
"we can't reach many of the people who contributed the original code under the old license, so we don't have the right to just switch the license. We'll have to rewrite some pretty big chunks of code before we can think about a more open license. That (the rewrite) is slated to happen for the next major release."
To me, the ability to both shrink and expand the filesystems is also essential. In brief, ext3 can be expanded and shrunk offline. XFS and JFS can only be expanded. ReiserFS supports both shrinking and expanding. IIRC, ReiserFS can be expanded, but not shrunk, online. XFS can probably only be expanded offline. I think JFS can only be expanded online (which I think is a bit weird, but OK
On my computer (with enough CPU power for it to probably not be a bottleneck - Athlon XP 2600+), these are some timings for operations like extracting a huge
(this looks terrible because I couldn't get even the ecode tag to work nicely, so it's a hack)From this it seems to me that overall reiser4 would be the clear winner when CPU is not the bottleneck. Unfortunately reiser4 didn't seem very stable although it was claimed "it's usable but still not recommended for production environments". Even during my tests I got repeatedly data loss, and after typically a couple of days of heavy reiser4 use top started to indicate that almost 100% of the CPU time was being spent in a syscall (and some processes became unkillable), a probable sign of a reiser4 operation in a syscall ending in an infinite loop (it didn't use disk in that loop though). I could not reproduce this kind of problems with any of the other filesystems.
I think reiser4 is definitely a promising filesystem with interesting concepts for systems with lots of CPU power, however as this is not the first time I've had problems with reiserfs (even production versions), it's going to be a while after it becomes stable after I'll be ready to even test it again and consider adopting it.
That's an interesting idea.
Now someone should write a clone of COMMAND.COM for Linux, for as we all know it's The Superior Command Interpreter(tm).
If you think that's ugly, I guess you've never seen the man page of pavuk (a robot like wget). The synopsis:
c e] [-ssl_key_file $file] [-ssl_cert_file $file] [-ssl_cert_passwd $pass] [-from $email] [-send_from/-nosend_from] [-identity $str] [-auto_referer/-noauto_referer] [-alang $list] [-acharset $list] [-retry $nr] [-nregets $nr] [-nredirs $nr] [-rollback $nr] [-sleep $nr] [-timeout $nr] [-preserve_time/-nopreserve_time] [-preserve_perm/-nopreserve_perm] [-preserve_slinks/-nopreserve_slinks] [-bufsize $nr] [-maxrate $nr] [-minrate $nr] [-user_condition $str] [-cookie_file $file] [-cookie_send/-nocookie_send] [-cookie_recv/-nocookie_recv] [-cookie_update/-nocookie_update] [-cookies_max $nr] [-disabled_cookie_domains $list] [-disable_html_tag $TAG,[$ATTRIB][;...]] [-enable_html_tag $TAG,[$ATTRIB][;...]] [-tr_del_chr $str] [-tr_str_str $str1 $str2] [-tr_chr_chr $chrset1 $chrset2] [-index_name $str] [-store_index/-nostore_index] [-store_name $str] [-debug/-nodebug] [-debug_level $level] [-browser $str] [-urls_file $file] [-file_quota $nr] [-trans_quota $nr] [-fs_quota $nr] [-enable_js/-disable_js] [-fnrules $t $m $r] [-store_info/-nostore_info] [-all_to_local/-noall_to_local] [-sel_to_local/-nosel_to_local] [-all_to_remote/-noall_to_remote] [-url_strategie $strategie] [-remove_adv/-noremove_adv] [-adv_re $RE] [-check_bg/-nocheck_bg] [-send_if_range/-nosend_if_range] [-sched_cmd $str] [-unique_log/-nounique_log] [-post_cmd $str] [-ssl_version $v] [-unique_sslid/-nounique_sslid] [-aip_pattern $re] [-dip_pattern $re][-use_http11/-nouse_http11] [-local_ip $addr] [-request $req] [-formdata $req] [-httpad $str] [-nthreads $nr] [-immesg/-noimmesg] [-dumpfd $nr] [-dump_urlfd $nr] [-unique_name/-nounique_name] [-leave_site_enter_dir/-dont_leave_site_enter_dir] [-max_time $nr] [-del_after/-nodel_after] [-singlepage/-nosinglepage] [-dump_after/-nodump_after] [-dump_response/-nodump_response] [-auth_ntlm_domain $str] [-auth_proxy_ntlm_domain $str] [-js_pattern $re] [-follow_cmd $str] [-retrieve_symlink/-noretrieve_symlink] [-js_transform $p $t $h $a] [-js_transform2 $p $t $h $a] [-ftp_proxy_user $str] [-ftp_proxy_pass $str] [-limit_inlines/-dont_limit_inlines] [-ftp_list_options $str] [-fix_wuftpd_list/-nofix_wuftpd_list] [-post_update/-nopost_update] [-info_dir $dir] [-mozcache_dir $dir] [-aport $list] [-dport $list] [-hack_add_index/-nohack_add_index] [-default_prefix $str] [-rsleep/-norsleep] [-ftp_login_handshake $host $handshake] [-js_script_file $file] [URLs]
pavuk [-mode {normal | resumeregets | singlepage | singlereget | sync | dontstore | ftpdir}] [-X] [-runX] [-bg/-nobg] [prefs/-noprefs] [-h] [-v] [-progress/-noprogress] [-stime/-nostime] [-xmaxlog $nr] [-logfile $file] [-slogfile $file] [-auth_file $file] [-msgcat $dir] [-language $str] [-gui_font $font] [-quiet/-verbose] [-cdir $dir] [-scndir $dir] [-scenario $str] [-dumpscn $filename] [-lmax $nr] [-dmax $nr] [-leave_level $nr] [-maxsize $nr] [-minsize $nr] [-asite $list] [-dsite $list] [-adomain $list] [-ddomain $list] [-asfx $list] [-dsfx $list] [-aprefix $list] [-dprefix $list] [-amimt $list] [-dmimet $list] [-pattern $pattern] [-url_pattern $pattern] [-rpattern $regexp] [-url_rpattern $regexp] [-skip_pattern $pattern] [-skip_url_pattern $pattern] [-skip_rpattern $regexp] [-skip_url_rpattern $regexp] [-newer_than $time] [-older_than $time] [-schedule $time] [-reschedule $nr] [-dont_leave_site/-leave_site] [-dont_leave_dir/-leave_dir] [-http_proxy $site[:$port]] [-ftp_proxy $site[:$port]] [-ssl_proxy $site[:$port]] [-gopher_proxy $site[:$port]] [-ftp_httpgw/-noftp_httpgw] [-ftp_dirtyproxy/-noftp_dirtyproxy] [-gopher_httpgw/-nogopher_httpgw] [-noFTP/-FTP] [-noHTTP/-HTTP] [-noSSL/-SSL] [-noGopher/-Gopher] [-FTPdir/-noFTPdir] [-noCGI/-CGI] [-FTPlist/-noFTPlist] [-FTPhtml/-noFTPhtml] [-noRelocate/-Relocate] [-force_reget/-noforce_reget] [-nocache/-cache] [-check_size/-nocheck_size] [-noRobots/-Robots] [-noEnc/-Enc] [-auth_name $user] [-auth_passwd $pass] [-auth_scheme 1/2/3/4/user/Basic/Digest/NTLM] [-auth_reuse_nonce/-no_auth_reuse_nonce] [-http_proxy_user $user] [-http_proxy_pass $pass] [-http_proxy_auth 1/2/3/4/user/Basic/Digest/NTLM] [-auth_reuse_proxy_nonce/-no_auth_reuse_proxy_non
Yes. Python doesn't (currently) do any kind of JIT compiling and is therefore purely an interpreted language and won't be affected by this change. To explain a bit further:
Basically we can divide programming languages (and environments) into compiled languages and interpreted languages. Compiled languages are usually fast but in many ways unsafe and the resulting programs are harder to observe. Interpreted languages are slow but observing and debugging the program is easy. Also a compiled program can only be run on a single architecture without recompiling while interpreted programs can be run on any architecture for which an interpreter exists.
Now there's a special class of languages that are compiled to bytecode which is closer to actual machine language than the source code yet independent from architecture. The resulting bytecode is run in a virtual machine (VM), which still has to interpret or compile it.
Often interpreting the bytecode is even slower than interpreting the original language. However, compiling the code and then running it only once is usually even slower than interpreting. The solution is to compile the code just in time (JIT) when it has possibly already been interpreted a few times and it seems likely it will be executed again and again. This way only the speed-critical parts of the program will ever be compiled, resulting in performance (arguably) close to compiled languages without tying the program to a single architecture.
Now, just as for any other compiler, from the JIT compiler's point of view both the bytecode and the compiled, machine-executable code is pure data. So the problem arises when the VM suddenly wants to transfer control from its interpreter code to the JIT-compiled code. The operating system has taken care of marking all the VM code as "OK to execute" when the program was started, but now no-one, unless the VM, has told the operating system that the new code is OK to execute. Therefore the OS cannot distinguish it from a case where a malicious user has fed machine code to a program as data and used a flaw in the program to jump into it, which is the way most common exploits work.
As for Python, I wouldn't actually classify it into bytecode languages, at least not yet. AFAIK the "bytecode" that Python scripts can be compiled into is more like a parse tree of the program than machine code, and the Python interpreter still purely interprets it. No generated machine code is executed at any point in time and hence the above scenario doesn't apply.
OK then. Given the http spec can write a provably correct web server? :-)
:)
And yes, I argue this can be done. Though with the current level of formal methods, it's quite a heavyweight problem. But it's a developing field.
In fact, source code is really just a very precise specification of what the computer has to do. It's so precise that it can be translated into an executable form automatically. :-)
:-) that f() is a function that always returns a prime number. This can be a very precise specification of the requirements of what f() must do - it must return a prime number. It's about abstraction, we don't specify anything we don't want to specify at this level.
Yes, that's true. The problem with it is that it cannot easily be split into abstract parts and be thus reasoned about. You can reason about bits and bytes, but that doesn't get you very far.
For example, we could specify (a silly example
Then we have a lower level specification that satisfies the higher level specification - for example, we specify that the function f() always returns a number from the set {2,3,5}. Then we prove that this satisfies the higher level specification, ie. f() really returns and it returns only prime numbers.
Then we get closer to the real implementation - we specify that f() always returns 3. It's easy to prove that this satisfies the former specification.
Now we write code for a function that always returns 3 and prove that it matches the specification. And suddenly we have an implementation of a function that always returns prime numbers. Other implementations might be possible.
Ok, this is too trivial an example. But a similar thing could be made for, say, a sorting function. We can specify that a function returns its parameters sorted. This way we have split the problem space into smaller parts: We need to prove that the given function works as specified, and then we can use the proved properties as axioms (ie. that the list is sorted and that it contains the same elements as the original list) in the higher level specification.