They don't load them with lots of free software. They load them up with lots of proprietary software, and pretty nasty stuff it is too. Even if you use 'free' to mean 'free of charge, gratis' that is not really accurate here, since the manufacturer is paid to install it on the PC. It's more like proprietary software that has a negative price.
Imagine writing a book that is 100% original material and fair use of other works, but still having to get permission from the copyright holder on the font to get the book published.
This is not the case at all. The printed image of a letter (or its bitmap when rasterized on a computer screen) is not copyrightable in the USA - perhaps for just the reason you describe. So you can scan and reprint existing printed texts without worrying about font copyright. Only the outline font data - the list of lines and curves to draw to generate a new printed glyph at a given resolution - can be subject to copyright.
Why are people calling this guy a 'scammer'? He sounds more like a simple extortionist.
Or is it simply that he is lying about murdering and kidnapping people, so tricking the victims into paying money when they get nothing in return? Maybe it would be more honest of him to really carry out the murders: then at least it wouldn't be a scam.
It does sound like an issue. Suppose an authoritative server responds to a query with a TTL of five minutes. That means it must not change the record during the next five minutes. After one minute the domain owner makes some change. Okay, there will be a lag of four minutes before it fully takes effect. Fine. But what if a second request is received a minute after the change? The authoritative server has to know that it has a change queued up to take effect in three minutes' time, and serve a reply with a TTL of three minutes or less. Moreover, it has to reply with the old version of the record, which is now known to be out of date. So internally it needs to keep track of old and new versions for each change, and keep serving the old version until the last TTL of a previous reply to that version expires. I doubt that all the various DNS servers across the net do this.
You are right but here we are talking about computer outline fonts, which are a set of data describing which lines and curves to draw. That is copyrightable, although bitmap fonts are not.
You are worried because someone, if they really wanted to send you some mail, could go to the trouble of doing a CPU-intensive search against some hash shown on a website and find out that ultimate, embarassing secret: your *email address*??
What gives? Email addresses are designed to be public. If you don't want people you do not know to be able to contact you, then you are free to drop all mail from unrecognized addresses. If you want to set up some kind of secret knowledge that people must have in order to contact you, then ask them to put a particular word in the subject line when first sending you a message. Either of these does not rely on keeping the address secret, which just isn't likely to happen.
The only thing more broken than trying to keep an email address secret is trying to make a 'private' web page by keeping the URI secret. Again, the system is designed so that the address itself is not sensitive, but other information such as a password or PGP key can be.
Actually, what it reminds me of most is the crazy situation in the US where a basically public identifier, the social security number, is abused as some kind of secret token. Hence all the fuss made when it is possible to find out someone's SSN. The answer is not to add more and more baroque means to stop the SSN from leaking out: one breach, and it's no longer a secret.
I understand the desire to stop spam address harvesters, but really, there are hundreds of web sites which display email addresses with only light obfuscation, enough to stop a harvester bot but not a determined human being (or someone determined enough to use an OCR engine). The kind of hashing talked about here is way more difficult to undo than that. If you are even more paranoid, you need to revisit your assumptions of what is public and what is secret.
Copyright on fonts makes a lot of sense, just as for music, novels, films and a lot of other stuff.
DRM, on the other hand, sounds like a thoroughly nasty idea; in jurisdictions with crazy laws like the DMCA, it could even make free software web browsers (that come with source code so you can modify them) illegal, just as free programs to play DVDs have been made illegal.
Yes - stack allocated variables which automatically get allocated memory when you enter a scope and are automatically freed when you leave the scope. Believe or not this automatic management (and yes 'auto' does stand for automatic) was once considered a big feature! It is so useful that 'auto' quickly became the default.
The next step, of course, is automatic freeing of objects on the heap, which is what the other poster was talking about when he said 'automatic memory management'. But if you really think that having memory managed automatically is always a bad thing, you wouldn't be using C at all.
Therefore a JIT compilation can generate faster code than a static compilation.
I completely agree, it can. All I am saying is that if you have a Javascript engine written in C, you can specalize it to execute a fixed string of Javascript code "x" instead of taking Javascript as an input. You now have a C program which does the same thing as the Javascript "x", and just as fast. Therefore if this JIT compiler is the only way you execute Javascript, you cannot say that Javascript is faster than C - no, not even if the JIT has super duper register colouring and dynamic loop unrolling - simply because for any Javascript code that runs fast, you could get at least the same performance from C code just by reusing the existing JIT and hardcoding the input string. I am not making any greater claim than that.
I'm not claiming that at all - there are certainly languages which are faster than C for many tasks. Examples are assembly language and K, and perhaps even ML if compiled to native code.
In this way, given a C compiler and a JIT Javascript compiler, both of which compile to native code with the same proficiency, the Javascript compiler will produce faster code,
I'm sure it will. But if the JIT Javascript compiler and runtime engine is itself written in C, then you can hardly say that Javascript is faster than C. After all you are running a C program either way. (Again, I'm thinking of a JIT compiler which does the compilation and runs the code immediately, not a separate compilation step where you generate code and save it to run later.)
The languages which are faster than C have one thing in common: they are not implemented in C!
For this reason the output of the JIT can be faster than C, even if the JIT is written in C.
Imagine writing a JIT for the C language instead of for Javascript. Then the output of the JIT can be faster than C, by your argument. So would that mean that C is faster than C?
I am not saying that the output of a JIT compiler (or any other compiler) cannot be faster than C, but that the whole package (a program which reads Javascript then does something to compile it and then runs it), if implemented in the C language, cannot be faster than C. If that package is your only choice for running Javascript, then Javascript cannot be faster than C. If someone wrote a standalone Javascript compiler then the situation would be different.
Once a C program makes a call to code not written in C, then it is no longer running C code.
Yes, I agree. I was only thinking of the case where the interpreter or JIT is written in C, not in mixture-of-C-and-something-else.
And you are surely right that you can't write a JIT-based Javascript engine in pure C but you need some assembler in there. In which case there is the potential for Javascript to execute faster than C, because Javascript running in this engine has access to all kinds of optimized assembly routines that aren't available from a plain C program and might be better than what your C compiler generates.
So I take your point. When I said 'C' I was really thinking 'you know, that language that Firefox or the JVM is written in'. Which is likely to be C++ anyway, but more than that, it will contain native assembly language too.
OK let me clarify one more time. What I am saying is equally true of an interpreter, or a JIT compiler, or a mixture of both. The important thing is that you have a C program which reads Javascript code and 'executes' it somehow. The exact mechanism for doing that is not important: it could run it line by line, or compile it into an intermediate bytecode and interpret that, or compile it just-in-time and run it, or even compile the whole Javascript program into a native executable which is then run.
If you have a C program which does this, you could easily make a specialized version of it which instead of reading in arbitrary Javascript code executes only a fixed string of Javascript.
Therefore, for any Javascript program run using the interpreter, or the JIT compiler, you can make an equivalent C program which is just as fast. Therefore interpreted or JIT-compiled Javascript can never be faster than C, unless you have an interpreter or JIT-compiler written in a language other than C (in which case it is at least possible).
By saying 'JIT-compiled languages can be considered a fast kind of interpreter' I meant from the user's point of view. If you just run the Javascript engine and you don't look at its source code or inspect how it works, there is no visible difference between an engine that works by interpreting and one that JIT-compiles. The JIT is likely to be faster, that's all. Of course under the hood they are completely different.
Exactly. It kind of makes you think the BSD folk might have a point in insisting on simple, permissive licences (though even those can be open to misinterpretation - see ipfilter in OpenBSD).
Still, this 15 page document is only needed for legal-corporate types, anxious to know the letter of the law and the exact boundaries of what's permitted. For ordinary programmers, RMS has tended to say that the letter of the GPL is less important than its spirit, which is to share your code and give all users the same rights you have. If you stick to that principle you can be pretty sure you are within the letter of the licence as well.
By a JIT I mean a program which acts like an interpreter, but is probably faster. It takes in source code and, somehow, turns it into native code which it executes immediately. So the compilation happens on the fly. From this point of view the JIT is a black box - the user doesn't see whether it is interpreting the code, making intermediate bytecode, compiling on the fly, or even compiling the whole program up front and then running it. All the user sees is how fast it runs, and whether the result is correct. It doesn't save any intermediate files or require any separate compilation steps.
If you write your JIT compiler in C then it takes the Javascript as input and outputs native code.
I had in mind a C program that takes Javascript source code and compiles it 'just in time' to run it. In that case, then, you can make a C program that does the same thing as the Javascript and at the same speed. You just specialize the C program to have a fixed string of Javascript code and run that.
If you allow a separate compilation stage - so Javascript gets compiled to native code, which is then executed - then it is certainly possible for it to run faster than C. But only if you don't count the compilation time as part of the benchmark!
So if I wrote a C compiler in Ruby, the generated code could never run as fast as Ruby?
If you wrote a C interpreter in Ruby (and yes, C interpreters do exist) then it could never be faster than Ruby. I was talking about interpreted languages (or JIT-compiled ones, which can be considered a fast kind of interpreter). If you allow yourself a separate compile step first (which is not included in the benchmark timing) and then run the compiled code, yes you can certainly get something faster.
That argument doesn't apply to JIT compilers, because you no longer have an interpreted language but a language which is compiled to native code without going through C.
Yes it does. If you have a JIT compiler (which is written in C) and a Javascript program, you can make a specialized version of the compiler to execute just that particular program. You now have a C program which does the same thing as the Javascript and runs just as fast.
Clearly no matter how fast the interpreted language goes it can never be faster than C, as long as the interpreter (or JIT, or whatever) is written in C. Given any Javascript program you could take the C code for the Javascript engine, include your Javascript code as a static string, and end up with a C program that performs the same task and runs just as fast. Therefore C will always be at least as quick as Javascript (until some day when Javascript compiles straight to native code without going through C).
The developers can be correct in all their statements. The Frozzbar interpreter might be nearly as fast as C right now for many common tasks. (For example, if you do network programming, the speed of the network will often be the limiting factor, and CPU-intensive things like gzip compression are calling native libraries anyway.) It won't be as fast as C for everything, but it will be close enough for most of the programs people typically write in Frozzbar. Then if the interpreter becomes 10x faster, the set of tasks for which Frozzbar is nearly as fast as C increases from maybe 80% of a typical programmer's job to 90%. It's still not faster than C though, because the Frozzbar interpreter itself is written in C.
Slashdot Mirror
They don't load them with lots of free software. They load them up with lots of proprietary software, and pretty nasty stuff it is too. Even if you use 'free' to mean 'free of charge, gratis' that is not really accurate here, since the manufacturer is paid to install it on the PC. It's more like proprietary software that has a negative price.
This is not the case at all. The printed image of a letter (or its bitmap when rasterized on a computer screen) is not copyrightable in the USA - perhaps for just the reason you describe. So you can scan and reprint existing printed texts without worrying about font copyright. Only the outline font data - the list of lines and curves to draw to generate a new printed glyph at a given resolution - can be subject to copyright.
Why are people calling this guy a 'scammer'? He sounds more like a simple extortionist.
Or is it simply that he is lying about murdering and kidnapping people, so tricking the victims into paying money when they get nothing in return? Maybe it would be more honest of him to really carry out the murders: then at least it wouldn't be a scam.
It does sound like an issue. Suppose an authoritative server responds to a query with a TTL of five minutes. That means it must not change the record during the next five minutes. After one minute the domain owner makes some change. Okay, there will be a lag of four minutes before it fully takes effect. Fine. But what if a second request is received a minute after the change? The authoritative server has to know that it has a change queued up to take effect in three minutes' time, and serve a reply with a TTL of three minutes or less. Moreover, it has to reply with the old version of the record, which is now known to be out of date. So internally it needs to keep track of old and new versions for each change, and keep serving the old version until the last TTL of a previous reply to that version expires. I doubt that all the various DNS servers across the net do this.
I guess not, but it seems silly to start making lots of noise and demanding cryptographically secure hashing to keep your email address top secret.
You say motherboard / daughterboard. I guess fatherboard / sonboard just doesn't have the same ring to it.
Compare mother cell / daughter cell in biology.
IBM always used to call it a 'planar' which at least sounds suitably nerdy.
You are right but here we are talking about computer outline fonts, which are a set of data describing which lines and curves to draw. That is copyrightable, although bitmap fonts are not.
You are worried because someone, if they really wanted to send you some mail, could go to the trouble of doing a CPU-intensive search against some hash shown on a website and find out that ultimate, embarassing secret: your *email address*??
What gives? Email addresses are designed to be public. If you don't want people you do not know to be able to contact you, then you are free to drop all mail from unrecognized addresses. If you want to set up some kind of secret knowledge that people must have in order to contact you, then ask them to put a particular word in the subject line when first sending you a message. Either of these does not rely on keeping the address secret, which just isn't likely to happen.
The only thing more broken than trying to keep an email address secret is trying to make a 'private' web page by keeping the URI secret. Again, the system is designed so that the address itself is not sensitive, but other information such as a password or PGP key can be.
Actually, what it reminds me of most is the crazy situation in the US where a basically public identifier, the social security number, is abused as some kind of secret token. Hence all the fuss made when it is possible to find out someone's SSN. The answer is not to add more and more baroque means to stop the SSN from leaking out: one breach, and it's no longer a secret.
I understand the desire to stop spam address harvesters, but really, there are hundreds of web sites which display email addresses with only light obfuscation, enough to stop a harvester bot but not a determined human being (or someone determined enough to use an OCR engine). The kind of hashing talked about here is way more difficult to undo than that. If you are even more paranoid, you need to revisit your assumptions of what is public and what is secret.
Copyright on fonts makes a lot of sense, just as for music, novels, films and a lot of other stuff.
DRM, on the other hand, sounds like a thoroughly nasty idea; in jurisdictions with crazy laws like the DMCA, it could even make free software web browsers (that come with source code so you can modify them) illegal, just as free programs to play DVDs have been made illegal.
Anyone who calls a motherboard a 'mainboard' deserves to fail.
Ahh... whatever happened to $$$exyGal, or $exy Gwen Stefani, or whatever 'she' was called?
He didn't say it was 2 square inches. He said it was 2 inches square, which means 2 inches by 2 inches.
I thought they pretty much standardized on mini-USB connectors for charging. If the device has a mini-USB connector anyway then it's an easy decision.
Yes - stack allocated variables which automatically get allocated memory when you enter a scope and are automatically freed when you leave the scope. Believe or not this automatic management (and yes 'auto' does stand for automatic) was once considered a big feature! It is so useful that 'auto' quickly became the default.
The next step, of course, is automatic freeing of objects on the heap, which is what the other poster was talking about when he said 'automatic memory management'. But if you really think that having memory managed automatically is always a bad thing, you wouldn't be using C at all.
I completely agree, it can. All I am saying is that if you have a Javascript engine written in C, you can specalize it to execute a fixed string of Javascript code "x" instead of taking Javascript as an input. You now have a C program which does the same thing as the Javascript "x", and just as fast. Therefore if this JIT compiler is the only way you execute Javascript, you cannot say that Javascript is faster than C - no, not even if the JIT has super duper register colouring and dynamic loop unrolling - simply because for any Javascript code that runs fast, you could get at least the same performance from C code just by reusing the existing JIT and hardcoding the input string. I am not making any greater claim than that.
I'm not claiming that at all - there are certainly languages which are faster than C for many tasks. Examples are assembly language and K, and perhaps even ML if compiled to native code.
I'm sure it will. But if the JIT Javascript compiler and runtime engine is itself written in C, then you can hardly say that Javascript is faster than C. After all you are running a C program either way. (Again, I'm thinking of a JIT compiler which does the compilation and runs the code immediately, not a separate compilation step where you generate code and save it to run later.)
The languages which are faster than C have one thing in common: they are not implemented in C!
Imagine writing a JIT for the C language instead of for Javascript. Then the output of the JIT can be faster than C, by your argument. So would that mean that C is faster than C?
I am not saying that the output of a JIT compiler (or any other compiler) cannot be faster than C, but that the whole package (a program which reads Javascript then does something to compile it and then runs it), if implemented in the C language, cannot be faster than C. If that package is your only choice for running Javascript, then Javascript cannot be faster than C. If someone wrote a standalone Javascript compiler then the situation would be different.
Yes, I agree. I was only thinking of the case where the interpreter or JIT is written in C, not in mixture-of-C-and-something-else.
And you are surely right that you can't write a JIT-based Javascript engine in pure C but you need some assembler in there. In which case there is the potential for Javascript to execute faster than C, because Javascript running in this engine has access to all kinds of optimized assembly routines that aren't available from a plain C program and might be better than what your C compiler generates.
So I take your point. When I said 'C' I was really thinking 'you know, that language that Firefox or the JVM is written in'. Which is likely to be C++ anyway, but more than that, it will contain native assembly language too.
OK let me clarify one more time. What I am saying is equally true of an interpreter, or a JIT compiler, or a mixture of both. The important thing is that you have a C program which reads Javascript code and 'executes' it somehow. The exact mechanism for doing that is not important: it could run it line by line, or compile it into an intermediate bytecode and interpret that, or compile it just-in-time and run it, or even compile the whole Javascript program into a native executable which is then run.
If you have a C program which does this, you could easily make a specialized version of it which instead of reading in arbitrary Javascript code executes only a fixed string of Javascript.
Therefore, for any Javascript program run using the interpreter, or the JIT compiler, you can make an equivalent C program which is just as fast. Therefore interpreted or JIT-compiled Javascript can never be faster than C, unless you have an interpreter or JIT-compiler written in a language other than C (in which case it is at least possible).
By saying 'JIT-compiled languages can be considered a fast kind of interpreter' I meant from the user's point of view. If you just run the Javascript engine and you don't look at its source code or inspect how it works, there is no visible difference between an engine that works by interpreting and one that JIT-compiles. The JIT is likely to be faster, that's all. Of course under the hood they are completely different.
Exactly. It kind of makes you think the BSD folk might have a point in insisting on simple, permissive licences (though even those can be open to misinterpretation - see ipfilter in OpenBSD).
Still, this 15 page document is only needed for legal-corporate types, anxious to know the letter of the law and the exact boundaries of what's permitted. For ordinary programmers, RMS has tended to say that the letter of the GPL is less important than its spirit, which is to share your code and give all users the same rights you have. If you stick to that principle you can be pretty sure you are within the letter of the licence as well.
I think we misunderstand each other.
By a JIT I mean a program which acts like an interpreter, but is probably faster. It takes in source code and, somehow, turns it into native code which it executes immediately. So the compilation happens on the fly. From this point of view the JIT is a black box - the user doesn't see whether it is interpreting the code, making intermediate bytecode, compiling on the fly, or even compiling the whole program up front and then running it. All the user sees is how fast it runs, and whether the result is correct. It doesn't save any intermediate files or require any separate compilation steps.
I had in mind a C program that takes Javascript source code and compiles it 'just in time' to run it. In that case, then, you can make a C program that does the same thing as the Javascript and at the same speed. You just specialize the C program to have a fixed string of Javascript code and run that.
If you allow a separate compilation stage - so Javascript gets compiled to native code, which is then executed - then it is certainly possible for it to run faster than C. But only if you don't count the compilation time as part of the benchmark!
If you wrote a C interpreter in Ruby (and yes, C interpreters do exist) then it could never be faster than Ruby. I was talking about interpreted languages (or JIT-compiled ones, which can be considered a fast kind of interpreter). If you allow yourself a separate compile step first (which is not included in the benchmark timing) and then run the compiled code, yes you can certainly get something faster.
Yes it does. If you have a JIT compiler (which is written in C) and a Javascript program, you can make a specialized version of the compiler to execute just that particular program. You now have a C program which does the same thing as the Javascript and runs just as fast.
Clearly no matter how fast the interpreted language goes it can never be faster than C, as long as the interpreter (or JIT, or whatever) is written in C. Given any Javascript program you could take the C code for the Javascript engine, include your Javascript code as a static string, and end up with a C program that performs the same task and runs just as fast. Therefore C will always be at least as quick as Javascript (until some day when Javascript compiles straight to native code without going through C).
The developers can be correct in all their statements. The Frozzbar interpreter might be nearly as fast as C right now for many common tasks. (For example, if you do network programming, the speed of the network will often be the limiting factor, and CPU-intensive things like gzip compression are calling native libraries anyway.) It won't be as fast as C for everything, but it will be close enough for most of the programs people typically write in Frozzbar. Then if the interpreter becomes 10x faster, the set of tasks for which Frozzbar is nearly as fast as C increases from maybe 80% of a typical programmer's job to 90%. It's still not faster than C though, because the Frozzbar interpreter itself is written in C.
Don't you have anyone in charge of making the coffee?