It really depends on the program. In the case of Bison, it spit out line after line of verbatum GPLd code. [...] All output for a true code generator would be derivative of your input. An example is the object code that comes out the other end of gcc.
While your point is valid, I think the distinction of source versus object code output is more important. (Although, given the linking issues w/ GNU Readline library, which is under GPL rather than LGPL, I suppose that your argument may carry more weight.)
Consider, for example, GNU C builtins. If I compile with a sufficiently high optimization level on modern versions of GCC, functions such as sin(), cos(), and so on get automagically inlined with built-in versions. (Granted, the inlining may not be verbatim--other optimization passes will more than likely affect the final form of the inlined functions.) One presumes the source for these built-in versions is GPL, and yet time after time, we are told that the object code output from GNU C is not considered a derived work of a GPL program due to this.
I don't see how having access to the code itself would give me the data it is processing. Care to explain that? It's one thing to have a bunch of database queries strapped to a UI. It's another thing to have the contents of the database that the code drives. For instance, I'd be surprised if there were any private subscriber information available in the Slashcode download.
Now, if the government had insecure machines and insecure procedures, then perhaps some information in the code would allow me to subvert their security. But that really is just security by obscurity, isn't it?
Generally, using a GPL tool to develop a program does not make the program itself GPL. For instance, compiling a non GPL program with GCC will not make the program magically GPL. Also, data output from a GPL program (eg. images created with GIMP, etc) is not covered by
the GPL.
The same is not true of program-generators though. Since program-generators often inject a portion of their own source into the output, and the output itself is source code, one would expect that the output is GPL'd. Program-generators such as Bison should include specific clauses to clarify the
situation. For instance, Bison's documentation
states:
Conditions for Using Bison
As of Bison version 1.24, we have changed the distribution terms for
`yyparse' to permit using Bison's output in non-free programs.
Formerly, Bison parsers could be used only in programs that were free
software.
The other GNU programming tools, such as the GNU C compiler, have
never had such a requirement. They could always be used for non-free
software. The reason Bison was different was not due to a special
policy decision; it resulted from applying the usual General Public
License to all of the Bison source code.
The output of the Bison utility--the Bison parser file--contains a
verbatim copy of a sizable piece of Bison, which is the code for the
`yyparse' function. (The actions from your grammar are inserted into
this function at one point, but the rest of the function is not
changed.) When we applied the GPL terms to the code for `yyparse', the
effect was to restrict the use of Bison output to free software.
We didn't change the terms because of sympathy for people who want to
make software proprietary. *Software should be free.* But we
concluded that limiting Bison's use to free software was doing little to
encourage people to make other software free. So we decided to make the
practical conditions for using Bison match the practical conditions for
using the other GNU tools.
So basically, if you use a GPL'd program generator, it's pretty clear that the output is GPL unless the program says it's not.
For the telephone-switch example, or heck--what about a Slash-based weblog? Neither case counts a redistribution, so no source distribution is required. Even for modified versions of the code.
Sure it is. If one disk of two in a non-striped configuration dies, you effectively lose half your data. If one disk of two in a striped configuration dies, you effectively lose ALL your data.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
This means there is potentially some flexibility
in how GPL versions are mixed and matched. And what happens when a GPL 2-or-greater package is integrated with GPL 3-only code? To you end up with GPL 2-or-greater as the combined license, or GPL 3-only?
I'm guessing that the net effect of this clause would be to reduce the impact of GPL 3's changes, so long as it's intermixed with GPL 2-and-up code. But IANAL. Some lawyers out there may interpret the above paragraph the other way, such that either GPL 3 code cannot intermix w/ GPL 2-and-up code, or that combining GPL 3-only code with GPL 2-and-up code gives a GPL 3 result. In that last case, GPL 3 could affect existing installations if some GPL 3-only code starts working its way in.
Version 3 of the GNU General Public License supposedly will add verbiage to cover application service providers, though. Basically, the idea is
if you take a GPL 3 application, patch it, and make its
functionality publicly
accessible, you're still liable for sharing the patches even though you haven't distributed the
binary.
GPL 3 is still vaporware, so the details may
change. But it is something to keep in mind,
especially if you deploy a commercial site that's backed by GPL software. If that software moves to a GPL 3 license, things could get interesting. I hope not in a bad way.
(Before you all scream "FUD", keep in mind that I release all my own code under GPL 2. I can't say the same about the code I write at work, but then my employer owns that code, not me.)
On 6.26am the morning of May 13th, 2001, the link is hit from IP 24.1.197.144 - a residential cable modem in Arizona, then on the @home network, now Cox. The browser is identified to the web server as a generic windows 95 version of Netscape. Of course it isn't, its an email harvesting robot that goes from web page to web page.
I think the translation you want is Taylor Series. Those infinitely long algebraic series for expressing transcendental functions line sine, cosine, etc. Right?
--Joe
1 one-thousand, 2 one-thousand, ....
on
Deep Algorithms?
·
· Score: 1
This is a BASIC program running on a real computer, and therefore it accepts inputs that are not explicitly written in the program.
One of these inputs is the BREAK keystroke (exact key depends on the type of computer). That input causes the program to halt. Another is the power connection. If this is removed, the algorithm halts as well.;-)
It would seem that all real computers are subject to the latter constraint.
Thus it would seem that all physically realizable programs (meaning, you can write them and run them on a machine, rather than just talk about them in broad terms) halt. Thus, in the grand scheme of things, they're ultimately eligible to be algorithms on this point
due to artifacts of the implementation.:-)
All sort algorithms can be made stable by putting the original positions into the keys you are sorting.
Thanks, I was just about to say that. It's an oft overlooked property, too. I generally feel that a sorting algorithm's stability is overrated, since you can easily
tack it onto any sort, usually for a low cost.
If you're sorting an array, all you need to do
is compare the two pointers to break ties. It's
that simple. It *does* get more complicated if you're sorting some other structure, such as a linked-list -- then you're stuck with an O(N) assignment phase before the sort, potentially,
and that brings with it extra storage requirements.
That sounds nice until you realize it's your
X server and xterms that'll get swapped out as
soon as you leave your workstation for a moment.
When you have to wait for *those* to come in
over the network, you'll be crying for local
swap once again.
Network swap is really only a useful option for
diskless workstations.
Also, zlib on windows wouldn't be exploitable, because double-frees on windows won't screw up like on linux.
Care to explain your reasoning behind that one?
Calling free() twice on the same pointer
typically is bad news. (Actually, some old
malloc implementations tolerated
certain forms of double-free from what I recall.) ZLib doesn't call free() directly, but rather relies on you to register a "ZMalloc" and "ZFree" hander that interface to your applications/environment's memory handler (usually, these call malloc and free, but aren't required to. In fact,
in places like the kernel, you must call something else -- kmalloc or vmalloc for instance.) Depending on how ZLib is integrated
with the rest of the app, a given program may
or may not be vulnerable to this particular
problem.
So how does that translate into "Linux is
vulnerable and Windows is not?" If both are
using ZLib, and vulnerability is tied to
ZLib and how it's integrated with the app,
then I think we can agree that OS doesn't
matter.
One place kernel uses zlib is to compress the kernel boot image. The kernel image then gets decompressed
during bootup. So, from the standpoint of "the kernel uses zlib", the kernel is affected.
There is, however, no new vulnerability introduced
as far as I can tell. To attack the zlib-based
decompression that the kernel performs, an attacker would need to modify the compressed kernel image that is used to boot the machine.
I can think of far more fruitful ways to
compromise a machine by modifying the kernel
image than by trying to dork the zlib decompression that happens before the kernel even runs.
Another place the kernel uses ZLib is when
mounting compressed filesystems. (Compressed
RAM disks and zisofs come to mind.) In this
case, you're asking a live kernel to decompress arbitrary data. These
are only issues when mounting untrusted media.
If you made the media yourself, then your
only risk is that corrupted media might cause
a kernel oops. And if you don't have cramdisk
and zisofs compiled in, you're safe.
Other places the kernel seems to use ZLib (from a cursory scan of the source -- there may be others):
jffs2 -- Journalling Flash Filesystem version 2
ppp -- used for ppp_deflate option
In any case, the kernel is a statically linked
entity, with a minor exception for modules.
ZLib is not a module, therefore to upgrade
ZLib in the kernel, you'll need to rebuild the
kernel. And it doesn't appear to be as easy as
just upgrading ZLib and rebuilding the kernel.
The kernel has multiple modified copies of ZLib
in its source tree. I'd wait for an official
kernel patch.
This is creepy. I was wondering about possible
vulnerabilities in zlib
earlier today for a completely different
reason.
According to this
post in a different article, a recent patch to Internet Explorer disables support for gzip encoding.
Do you think, perhaps, Microsoft noticed the bug,
shut off the support (since presumably they're
just using zlib also), and just didn't say anything?
Of course, that is just paranoia. They could have plenty of other reasons.
--Joe
Re:How to modem accelerate as a webmaster
on
Modem Accelerators?
·
· Score: 1
No, that'd be the table formatting. Unzipping is about the same level of complexity as decoding a GIF of comparable size. And I know Quadras can decompress 70K GIFs in far less than 5 minutes.
In contrast, Netscape 4.x with tables of any size can take forever to render, and it seems to take the rest of the machine with it while it does. (At least, on some machines.)
It could be the difference between 16MB and 32MB of RAM. GCC processes aren't tiny. And if you're running X, watch out.
FWIW, my 486-class machine (an AMD 5x86-133) has
64 MB of RAM, and its much happier. However, there's a memory leak (2.2.19 leaks memory whenever dhcpcd renews my lease -- I suspect it's related to IP Masquerading, which I also run though that box). When memory starts getting low (all that leaked memory is unpageable), the machine performance falls off a cliff.
Thankfully, it leaks slowly enough that I only reboot that machine once every 3 months or so.
The last time I tried to build a kernel on there,
it took probably close to an hour or more. Typically, though, this guy sig-11's out of the compile. He's getting old and tired.
That bit actually represented more than 1 bit's
worth of storage -- it was closer to 2.1 bits or so.
Bit was a superset of the
"tristate" -- High-Z (idle), Zero (No), and One (Yes). To that TRON's Bit adds two more states -- Really No (NO NO NO), and Really Yes (YES YES YES).
To clarify, it appears Ken Perlin got his Oscar for "Perlin Noise", which he generated after doing
TRON. He actually set about developing Perlin noise in 1983 after being frustrated by TRON's heavy computerish look.
Ah yes, nothing quite like the familiar "TCH! sssshhHHHHhhhh!" of sending a disc through one of the bad guys.
I actually asked Keith Robinson (one of the Mattel Programmers) during a panel at CGExpo why the bad guys were blue and the good guys red in Tron. He dismissed the
question as the geekiest question he'd heard.:-) (scroll down the page to see the paragraph mentioning the question.)
I found out later from a friend that apparently Disney had dithered back and forth right up until
the end on what colors the good guys and bad guys would have. Apparently, the Mattel folks had worked from a pre-screening which had the good guys in red and the bad in blue.
(I tried to find a link to the article my friend sent me, but Dave's Videogame Classics seems to have
gone away.)
<plug type=shameless>
Speaking of Intellivision, I'm actively developing
games for it. I've released one game called
4-Tris
and I'm presently working on another. I've even
made cartridges!:-) </plug>
Slashdot Mirror
While your point is valid, I think the distinction of source versus object code output is more important. (Although, given the linking issues w/ GNU Readline library, which is under GPL rather than LGPL, I suppose that your argument may carry more weight.)
Consider, for example, GNU C builtins. If I compile with a sufficiently high optimization level on modern versions of GCC, functions such as sin(), cos(), and so on get automagically inlined with built-in versions. (Granted, the inlining may not be verbatim--other optimization passes will more than likely affect the final form of the inlined functions.) One presumes the source for these built-in versions is GPL, and yet time after time, we are told that the object code output from GNU C is not considered a derived work of a GPL program due to this.
--JoeI don't see how having access to the code itself would give me the data it is processing. Care to explain that? It's one thing to have a bunch of database queries strapped to a UI. It's another thing to have the contents of the database that the code drives. For instance, I'd be surprised if there were any private subscriber information available in the Slashcode download.
Now, if the government had insecure machines and insecure procedures, then perhaps some information in the code would allow me to subvert their security. But that really is just security by obscurity, isn't it?
--JoeNo, because then they'd be stealing.
Oh, wait, I guess there is some tolerance for going to the bathroom... ;-)
--JoeGenerally, using a GPL tool to develop a program does not make the program itself GPL. For instance, compiling a non GPL program with GCC will not make the program magically GPL. Also, data output from a GPL program (eg. images created with GIMP, etc) is not covered by the GPL.
The same is not true of program-generators though. Since program-generators often inject a portion of their own source into the output, and the output itself is source code, one would expect that the output is GPL'd. Program-generators such as Bison should include specific clauses to clarify the situation. For instance, Bison's documentation states:
So basically, if you use a GPL'd program generator, it's pretty clear that the output is GPL unless the program says it's not.
For the telephone-switch example, or heck--what about a Slash-based weblog? Neither case counts a redistribution, so no source distribution is required. Even for modified versions of the code.
--JoeSure it is. If one disk of two in a non-striped configuration dies, you effectively lose half your data. If one disk of two in a striped configuration dies, you effectively lose ALL your data.
--JoeMy thoughts exactly. Ironic that a "turbo-laser" would be slower than a real laser...
--JoeI was just thinking about that also. It makes Eben Moglen's arguments about GPL's superiority somewhat ironic, actually.
It'll be interesting to see exactly how GPL 3 achieves its aims of addressing ASPs without losing this desirable characteristic of the GPL.
--JoeOn a related note, Version 2 of the GPL says:
This means there is potentially some flexibility in how GPL versions are mixed and matched. And what happens when a GPL 2-or-greater package is integrated with GPL 3-only code? To you end up with GPL 2-or-greater as the combined license, or GPL 3-only?
I'm guessing that the net effect of this clause would be to reduce the impact of GPL 3's changes, so long as it's intermixed with GPL 2-and-up code. But IANAL. Some lawyers out there may interpret the above paragraph the other way, such that either GPL 3 code cannot intermix w/ GPL 2-and-up code, or that combining GPL 3-only code with GPL 2-and-up code gives a GPL 3 result. In that last case, GPL 3 could affect existing installations if some GPL 3-only code starts working its way in.
--JoeVersion 3 of the GNU General Public License supposedly will add verbiage to cover application service providers, though. Basically, the idea is if you take a GPL 3 application, patch it, and make its functionality publicly accessible, you're still liable for sharing the patches even though you haven't distributed the binary.
GPL 3 is still vaporware, so the details may change. But it is something to keep in mind, especially if you deploy a commercial site that's backed by GPL software. If that software moves to a GPL 3 license, things could get interesting. I hope not in a bad way.
(Before you all scream "FUD", keep in mind that I release all my own code under GPL 2. I can't say the same about the code I write at work, but then my employer owns that code, not me.)
--JoeIt could be spammers harvesting addresses, as this page indicates.
Tada.
--JoeMuch too long. You want:
$0&$0
Does almost the same thing, only faster. If you still want the pipes, go a character longer: $0|$0&
--JoeI think the translation you want is Taylor Series. Those infinitely long algebraic series for expressing transcendental functions line sine, cosine, etc. Right?
--JoeThe guessing, the program, or both?
--JoeThis is a BASIC program running on a real computer, and therefore it accepts inputs that are not explicitly written in the program.
One of these inputs is the BREAK keystroke (exact key depends on the type of computer). That input causes the program to halt. Another is the power connection. If this is removed, the algorithm halts as well. ;-)
It would seem that all real computers are subject to the latter constraint. Thus it would seem that all physically realizable programs (meaning, you can write them and run them on a machine, rather than just talk about them in broad terms) halt. Thus, in the grand scheme of things, they're ultimately eligible to be algorithms on this point due to artifacts of the implementation. :-)
--JoeThanks, I was just about to say that. It's an oft overlooked property, too. I generally feel that a sorting algorithm's stability is overrated, since you can easily tack it onto any sort, usually for a low cost. If you're sorting an array, all you need to do is compare the two pointers to break ties. It's that simple. It *does* get more complicated if you're sorting some other structure, such as a linked-list -- then you're stuck with an O(N) assignment phase before the sort, potentially, and that brings with it extra storage requirements.
--JoeThat sounds nice until you realize it's your X server and xterms that'll get swapped out as soon as you leave your workstation for a moment. When you have to wait for *those* to come in over the network, you'll be crying for local swap once again.
Network swap is really only a useful option for diskless workstations.
--JoeCare to explain your reasoning behind that one? Calling free() twice on the same pointer typically is bad news. (Actually, some old malloc implementations tolerated certain forms of double-free from what I recall.) ZLib doesn't call free() directly, but rather relies on you to register a "ZMalloc" and "ZFree" hander that interface to your applications/environment's memory handler (usually, these call malloc and free, but aren't required to. In fact, in places like the kernel, you must call something else -- kmalloc or vmalloc for instance.) Depending on how ZLib is integrated with the rest of the app, a given program may or may not be vulnerable to this particular problem.
So how does that translate into "Linux is vulnerable and Windows is not?" If both are using ZLib, and vulnerability is tied to ZLib and how it's integrated with the app, then I think we can agree that OS doesn't matter.
--JoeOne place kernel uses zlib is to compress the kernel boot image. The kernel image then gets decompressed during bootup. So, from the standpoint of "the kernel uses zlib", the kernel is affected. There is, however, no new vulnerability introduced as far as I can tell. To attack the zlib-based decompression that the kernel performs, an attacker would need to modify the compressed kernel image that is used to boot the machine. I can think of far more fruitful ways to compromise a machine by modifying the kernel image than by trying to dork the zlib decompression that happens before the kernel even runs.
Another place the kernel uses ZLib is when mounting compressed filesystems. (Compressed RAM disks and zisofs come to mind.) In this case, you're asking a live kernel to decompress arbitrary data. These are only issues when mounting untrusted media. If you made the media yourself, then your only risk is that corrupted media might cause a kernel oops. And if you don't have cramdisk and zisofs compiled in, you're safe.
Other places the kernel seems to use ZLib (from a cursory scan of the source -- there may be others):
In any case, the kernel is a statically linked entity, with a minor exception for modules. ZLib is not a module, therefore to upgrade ZLib in the kernel, you'll need to rebuild the kernel. And it doesn't appear to be as easy as just upgrading ZLib and rebuilding the kernel. The kernel has multiple modified copies of ZLib in its source tree. I'd wait for an official kernel patch.
--JoeThis is creepy. I was wondering about possible vulnerabilities in zlib earlier today for a completely different reason.
According to this post in a different article, a recent patch to Internet Explorer disables support for gzip encoding. Do you think, perhaps, Microsoft noticed the bug, shut off the support (since presumably they're just using zlib also), and just didn't say anything?
Of course, that is just paranoia. They could have plenty of other reasons.
--JoeNo, that'd be the table formatting. Unzipping is about the same level of complexity as decoding a GIF of comparable size. And I know Quadras can decompress 70K GIFs in far less than 5 minutes.
In contrast, Netscape 4.x with tables of any size can take forever to render, and it seems to take the rest of the machine with it while it does. (At least, on some machines.)
--JoeIt could be the difference between 16MB and 32MB of RAM. GCC processes aren't tiny. And if you're running X, watch out.
FWIW, my 486-class machine (an AMD 5x86-133) has 64 MB of RAM, and its much happier. However, there's a memory leak (2.2.19 leaks memory whenever dhcpcd renews my lease -- I suspect it's related to IP Masquerading, which I also run though that box). When memory starts getting low (all that leaked memory is unpageable), the machine performance falls off a cliff.
Thankfully, it leaks slowly enough that I only reboot that machine once every 3 months or so.
The last time I tried to build a kernel on there, it took probably close to an hour or more. Typically, though, this guy sig-11's out of the compile. He's getting old and tired.
--JoeNah, real programmers just cat > program ; chmod +x ./program and get on with it.
--JoeThat bit actually represented more than 1 bit's worth of storage -- it was closer to 2.1 bits or so.
Bit was a superset of the "tristate" -- High-Z (idle), Zero (No), and One (Yes). To that TRON's Bit adds two more states -- Really No (NO NO NO), and Really Yes (YES YES YES).
--JoeTo clarify, it appears Ken Perlin got his Oscar for "Perlin Noise", which he generated after doing TRON. He actually set about developing Perlin noise in 1983 after being frustrated by TRON's heavy computerish look.
Here is a talk by Ken himself which is somewhat enlightening on the technique.
--JoeAh yes, nothing quite like the familiar "TCH! sssshhHHHHhhhh!" of sending a disc through one of the bad guys. I actually asked Keith Robinson (one of the Mattel Programmers) during a panel at CGExpo why the bad guys were blue and the good guys red in Tron. He dismissed the question as the geekiest question he'd heard. :-) (scroll down the page to see the paragraph mentioning the question.)
I found out later from a friend that apparently Disney had dithered back and forth right up until the end on what colors the good guys and bad guys would have. Apparently, the Mattel folks had worked from a pre-screening which had the good guys in red and the bad in blue. (I tried to find a link to the article my friend sent me, but Dave's Videogame Classics seems to have gone away.)
<plug type=shameless> Speaking of Intellivision, I'm actively developing games for it. I've released one game called 4-Tris and I'm presently working on another. I've even made cartridges! :-) </plug>
--Joe