In the case we're talking about, the program does not share the memory space until the user runs it. If it's a derivitave work, the user is creating the derivative at runtime. As I pointed out, the user probably can do this if he chooses.
If just writing a program that can call a particular API (in process or not) causes it to be a derivitave work of some library that implements that API, then the whole GNU project (a straight clone of UNIX, including its APIs) would be toast.
Even if I'm wrong and you're right, somebody could always write an RPC proxy between the GPL'd library and the proprietary program. Once this proxy exists, then the program becomes legal to distribute, because there exists a workaround. Regardless, as I explained before, the end user is entitled to do a direct link anyway, so nobody would need to actually use the RPC proxy. At this point, it all becomes a pointless exercise in semantics.
So I looked at the FAQ and the GPL again. Clearly, I can't redistribute a GPL'd program that I've modified to depend on a proprietary program. However, the question here was whether I could distribute a proprietary program that depends on a GPL'd program. The proprietary program would be distributed by itself; the end user would have to obtain the GPL'd library.
I still maintain that the GPL can in no way affect my distribution of my program. It is not a deriviative work until it is actually linked. Just because it doesn't do anything by itself doesn't mean I can't sell it; there's no guarantee that anybody will ever try to link it to the GPL'd code. Nor is there a guarantee that a compatible non-GPL'd library doesn't exist or will never exist.
The question then boils down to whether the end user can legally link the two parts together and use them. That's a stickier question. However, here's the actual restriction from the GPL:
You may not copy, modify, sublicense, distribute or transfer the Program except as expressly provided under this General Public License.
If the end user were to install (copy) the GPL'd library first before running it with the proprietary program, then he would no longer be covered by any of the above restrictions (which do not prohibit using the program). The next sentence in the GPL forbids using the program if you violate the above conditions, but the user isn't violating them as written.
The end-user would probably considered to be "modifying" the GPL'd library by linking it to form the derived work. However, the GPL only says (in paragraph 2a) that the user must place notices on modified files (he modified none), and (in paragraph 2b) that if he redistributes it, the whole thing is GPL'd. Obviously, the end user couldn't redistribute it. But I still think he can get away with just using it.
If you write an application that links (dynamically or statically it doesn't matter) with a GPLed library then you must distribute your application under the GPL (assuming you distribute your application). This doesn't "lock" the interface or the API because you are perfectly free to create your own replacement for libfoo (called libbar, of course). Example: libedit is a replacement for readline.
That doesn't make any sense to me. If (as the parent post assumed) you're not distributing libfoo, how can you violate its copyright? The situation you're presenting seems to require some kind of "quantum entanglement" between the existence of a compatible libbar and the legality of distributing a program that is able to link to libfoo.
How about a simpler example. I write a Windows program; it can't run without Windows. Does that make it a "derivitave work" of windows? Is Microsoft entitled to royalties on my program?
The whole argument is moot. Irrespective of this "Washing Rights Management", it seems unlikely that there exists a single ThinkGeek t-shirt that has ever seen the inside of any kind of washing machine.
"NT 3.51 was a very unrewarding release," Thompson said, contrasting it with Daytona. "After Daytona was completed, we basically sat around for 9 months fixing bugs while we waited for IBM to finish the Power PC hardware. But because of this, NT 3.51 was a solid release, and our customers loved it." NT 3.51 eventually shipped in May 1995.
I guess this statement neatly sums up the attitude behind much of their corporate culture.
Look on the bright side. What makes Saturn the coolest looking planet in the solar system? Its rings!
Soon, through a process similar to that which created Saturn's rings, Earth could have its own rings. And being made of mostly metal, plastic and paint, our rings would be especially shiny and colorful.
When I feel a cracker attack coming on, I don't sit around waiting to "lure" crackers. Instead, I just head down to the local supermarket and buy a few boxes.
There's no need to deal with sticky messy honeypots, either. You can get Honey Grahams with the delicious honey flavor baked right in.
I can see the retirees in Florida now as they try to enter their vote:
[voter@miami-booth-323]$ vote -T Republican -x senate:Reno, mayor:Phillips -p 32:yes, 47:no vote: Invalid paramters. [voter@miami-booth-323]$ vote --help Vote for candidates. USAGE: vote [-kKeiAvcIJx [-T party] [[-xkjJT] office:(name|party) [,...]] | [-qET] propnum:(yes|no) [,...] ]... [voter@miami-booth-323]$ man vote No manual entry for vote [voter@miami-booth-323]$ apropos vote vote: nothing appropriate [voter@miami-booth-323]$ info vote This is the top of the INFO tree ... [voter@miami-booth-323]$ crap bash: crap: command not found [voter@miami-booth-323]$
The first atomic bomb was revolution. Subsequent advances in power constituted evolution.
The first atomic bomb was 3 orders of magnitude larger than the largest conventional weapons.
The biggest thermonuclear bombs were another 3 orders of magnitude larger than the first atomic bomb. The increase in capabilities was just as significant, but it's hard for people to absorb that because the pictures of the explosions lack scaling context and look superficially similar.
Moving from being able to wreck a few cities with A-bombs to threatening the very existence of civilization itself (mosly through monumental releases of fallout and soot) seems revolutionary to me.
They really (Compaq and HP) are trying their damndest to stop making _anything_, it seems to me.
That's because they know that in the future, inkjet cartridges will account for 100% of all revenue in the computer industry. All other hardware and software will be given away free of charge as promotional material to generate more sales of inkjet ink.
Re:Google's decision is economic
on
Forget Moore's Law?
·
· Score: 2, Interesting
But as CPUs get faster, more and more problems can be parallelized at the granularity of a commodity CPU. That leaves fewer problems left that demand a new, faster CPU.
Eventually, the dwindling number of remaining problems won't have enough funding behind them to support the frantic pace of innovation needed to support Moore's law. I think that CPU development will hit this economic barrier well before it becomes technically impossible to improve performance.
I think that this makes sense using some kind of bogo-calculus. It's like a huge differential equation with boundary conditions = zero at one end and infinity at the other: nothing and everything. Something has to fill the space between, it might as well be the universe as we know it.
If you have a big crunch, the boundary conditions at both ends are zero, and it's harder to imagine why anything would happen in the first place.
Mabye the big bang wasn't driven internally so much as it was (is?) sucked out of nothingness by the infinity at the other end of time.
Well, the question is if the Athlon 64 would increase sells and processor prices that mutch that switching to an even more expensive die would bring any benefit to AMDs financal position - especially when there is no Windows(tm) 64 available, for sure a great disadvantage for marketing.
However, we should never underestimate the power of the Spinal Tap marketing message:
"But these go to sixty-four!"
Nobody in business is going to buy an AMD chip, which is by definition an emulator
All X86 CPUs are "emulators", regardless of who manufactures them. The real guts of a P4 look nothing at all like you would expect from the opcodes you feed into it. It's emulating that 25 year old architecture.
Since AMD has been producing X86 CPUs since the days of the 8086, I would argue that they have just about as much experience in emulating X86 CPUs as intel does.
Now, my old friend, the Waffle Iron, needs some help understanding part of MIT's system. Someone who tried to mod a public terminal for their own use is likely to be bit by this dog [mit.edu].
How does Kerberos prevent local hardware or software tampering with a terminal? It is an authentication method for talking to servers.
If your local terminal is compromised, all bets are off.
Any workstation that is pysically accessible to the public is subject to reprogrammning so that it emulates its original behavior plus logs keystrokes. Unless you're using honest-to-goodness dumb terminals with non-flashable ROMs, I wouldn't be so confident.
For example a passing stinger missile obtained from Uncle Sam by way of the Taleban.
Ummm... I thought that a stinger missile uses only infrared guidence. Those missiles are not likely to be talking to an electronic gadget on the space shuttle, nor are they likely to be effective after the first few seconds of liftoff (when the engines are on and the vehicle is in range of the stinger). Even at liftoff, I would guess that a stinger might be incinerated by the exhaust plume before it reaches the shuttle.
The reason all of your arguments about evolution end up in circles is that you can invoke the "faith" hyperspace button to jump back to square one whenever you are cornered.
If there was an explosion in the service module of an Apollo mission, they might be able to make enough kludges get back to earth safely. However, with all the ambiguities, it probably wouldn't be worth going through the effort.
Open Source at it's best - a bunch of bitchy whining children.
The only difference between the bitchy whining children in open source development and the bitchy whining children in closed source development is that the latter have signed NDAs that keep the pissing contests out of the public spotlight.
64 bits is fine and dandy, but the convoluted instruction set, seemingly random usage of registers, and an inability to do fast floating point operations really hampers the x86 system.
The instruction set and register layout is irrelevant. All modern X86 CPUs translate the inctruction stream on-the-fly to an internal RISC-like architecture with multiple parallel execution units. Using register renaming, all modern X86 CPUs have dozens of general-purpose physical registers that can be simultaneously mapped onto the legacy logical registers.
There is no need to expose the internals of any particular CPU generation to the software because the details change with each new design. The CPU's on-the-fly recoding knows how to optimize for the details of its particular internal implementation better than a C compiler. (Exposing the implementation details to the compiler is one reason why I think that the whole Itanium concept is a bad idea in the long run.)
The floating point performance is a function of the target market. If a CPU manufacturer was so inclined, they could create an X86 with world-record FPU performance. It's just not needed for the majority of places where X86's get used today.
Slashdot Mirror
If just writing a program that can call a particular API (in process or not) causes it to be a derivitave work of some library that implements that API, then the whole GNU project (a straight clone of UNIX, including its APIs) would be toast.
Even if I'm wrong and you're right, somebody could always write an RPC proxy between the GPL'd library and the proprietary program. Once this proxy exists, then the program becomes legal to distribute, because there exists a workaround. Regardless, as I explained before, the end user is entitled to do a direct link anyway, so nobody would need to actually use the RPC proxy. At this point, it all becomes a pointless exercise in semantics.
I still maintain that the GPL can in no way affect my distribution of my program. It is not a deriviative work until it is actually linked. Just because it doesn't do anything by itself doesn't mean I can't sell it; there's no guarantee that anybody will ever try to link it to the GPL'd code. Nor is there a guarantee that a compatible non-GPL'd library doesn't exist or will never exist.
The question then boils down to whether the end user can legally link the two parts together and use them. That's a stickier question. However, here's the actual restriction from the GPL:
If the end user were to install (copy) the GPL'd library first before running it with the proprietary program, then he would no longer be covered by any of the above restrictions (which do not prohibit using the program). The next sentence in the GPL forbids using the program if you violate the above conditions, but the user isn't violating them as written.
The end-user would probably considered to be "modifying" the GPL'd library by linking it to form the derived work. However, the GPL only says (in paragraph 2a) that the user must place notices on modified files (he modified none), and (in paragraph 2b) that if he redistributes it, the whole thing is GPL'd. Obviously, the end user couldn't redistribute it. But I still think he can get away with just using it.
That doesn't make any sense to me. If (as the parent post assumed) you're not distributing libfoo, how can you violate its copyright? The situation you're presenting seems to require some kind of "quantum entanglement" between the existence of a compatible libbar and the legality of distributing a program that is able to link to libfoo.
How about a simpler example. I write a Windows program; it can't run without Windows. Does that make it a "derivitave work" of windows? Is Microsoft entitled to royalties on my program?
In order to satisfy all of the interested parties, it really ought to be called "{ G/L (but not W) }indowsOS"
The whole argument is moot. Irrespective of this "Washing Rights Management", it seems unlikely that there exists a single ThinkGeek t-shirt that has ever seen the inside of any kind of washing machine.
I guess this statement neatly sums up the attitude behind much of their corporate culture.
Soon, through a process similar to that which created Saturn's rings, Earth could have its own rings. And being made of mostly metal, plastic and paint, our rings would be especially shiny and colorful.
There's no need to deal with sticky messy honeypots, either. You can get Honey Grahams with the delicious honey flavor baked right in.
Given the skyrocketing sales of duct tape this past week, I'm guessing there's a lot of people who are going to try patching anyway.
I can see the retirees in Florida now as they try to enter their vote:
The first atomic bomb was 3 orders of magnitude larger than the largest conventional weapons.
The biggest thermonuclear bombs were another 3 orders of magnitude larger than the first atomic bomb. The increase in capabilities was just as significant, but it's hard for people to absorb that because the pictures of the explosions lack scaling context and look superficially similar.
Moving from being able to wreck a few cities with A-bombs to threatening the very existence of civilization itself (mosly through monumental releases of fallout and soot) seems revolutionary to me.
That's because they know that in the future, inkjet cartridges will account for 100% of all revenue in the computer industry. All other hardware and software will be given away free of charge as promotional material to generate more sales of inkjet ink.
Eventually, the dwindling number of remaining problems won't have enough funding behind them to support the frantic pace of innovation needed to support Moore's law. I think that CPU development will hit this economic barrier well before it becomes technically impossible to improve performance.
If you have a big crunch, the boundary conditions at both ends are zero, and it's harder to imagine why anything would happen in the first place.
Mabye the big bang wasn't driven internally so much as it was (is?) sucked out of nothingness by the infinity at the other end of time.
However, we should never underestimate the power of the Spinal Tap marketing message: "But these go to sixty-four!"
All X86 CPUs are "emulators", regardless of who manufactures them. The real guts of a P4 look nothing at all like you would expect from the opcodes you feed into it. It's emulating that 25 year old architecture.
Since AMD has been producing X86 CPUs since the days of the 8086, I would argue that they have just about as much experience in emulating X86 CPUs as intel does.
How does Kerberos prevent local hardware or software tampering with a terminal? It is an authentication method for talking to servers.
If your local terminal is compromised, all bets are off.
Any workstation that is pysically accessible to the public is subject to reprogrammning so that it emulates its original behavior plus logs keystrokes. Unless you're using honest-to-goodness dumb terminals with non-flashable ROMs, I wouldn't be so confident.
Ummm... I thought that a stinger missile uses only infrared guidence. Those missiles are not likely to be talking to an electronic gadget on the space shuttle, nor are they likely to be effective after the first few seconds of liftoff (when the engines are on and the vehicle is in range of the stinger). Even at liftoff, I would guess that a stinger might be incinerated by the exhaust plume before it reaches the shuttle.
The reason all of your arguments about evolution end up in circles is that you can invoke the "faith" hyperspace button to jump back to square one whenever you are cornered.
I use a Commodore VIC-20 for this purpose. It has just enough memory to hold that file named "COPYING".
If there was an explosion in the service module of an Apollo mission, they might be able to make enough kludges get back to earth safely. However, with all the ambiguities, it probably wouldn't be worth going through the effort.
Without the heatsink, a silicon CPU wouldn't be solid for very long.
(As for your hypothetical silicone CPU, it probably wouldn't be considered fully solid even at room temperature.)
The only difference between the bitchy whining children in open source development and the bitchy whining children in closed source development is that the latter have signed NDAs that keep the pissing contests out of the public spotlight.
The instruction set and register layout is irrelevant. All modern X86 CPUs translate the inctruction stream on-the-fly to an internal RISC-like architecture with multiple parallel execution units. Using register renaming, all modern X86 CPUs have dozens of general-purpose physical registers that can be simultaneously mapped onto the legacy logical registers.
There is no need to expose the internals of any particular CPU generation to the software because the details change with each new design. The CPU's on-the-fly recoding knows how to optimize for the details of its particular internal implementation better than a C compiler. (Exposing the implementation details to the compiler is one reason why I think that the whole Itanium concept is a bad idea in the long run.)
The floating point performance is a function of the target market. If a CPU manufacturer was so inclined, they could create an X86 with world-record FPU performance. It's just not needed for the majority of places where X86's get used today.