You're assuming the sig is intended as a release. I read it as a factual clarification- nothing more than a reminder of the law, current and probable.
Re:Why I Can't make a DOOM 3 clone
on
Razor Blade Games?
·
· Score: 2, Insightful
I could write the first DOOM engine. I could probably even write something like Quake 2.
I could probably write something like Quake 2... oh wait, I've got the whole Quake2 source code right here! Nevermind.
If you're a small developer, the excuse of not having a basis to start from doesn't hold up. Carmack has graciously released his code to the public well before it became fully obselete.
As mentioned in other responses, the majority of the work for a new game is in graphic/level resources. The fact that your binaries are GPL won't hurt your commercial prospects very much- customers still have to pay to play the game experience you've designed.
(And if the code you do change is GPL, then you have the added potential benefit of leveraging changes made by other small game developers)
Games are more like books. All a game writer needs is a computer with some appropriate tools and a target platform set up for development.
By the definition of "game" as the authors of the original article were thinking about it, that isn't true. There has been a kind of fork in game development over the past 6-10 years.
In 1994 or so, "garage" games could still be popular. 10 talented guys working for 9 months could publish Doom or some other blockbuster title.
But since then, computers have gotten more and more storage space and output A/V quality. To make good use of all that power, you need large, high-quality artwork resources, and lots of them. (Look at how Everquest can't even run with 512 meg of RAM- yet it's graphics aren't top-quality). The cost to produce a game that can sit on a store shelf has ballooned to where it's comprable to Hollywood films.
No single author or small team can produce a game that'll earn money on the console or PC market.
Now, there has been a divergent path for game developers which has become more prominent in the past year. Web-based (flash, java, or small downloads of native binraries) have become popular and somewhat profitable (often advertising-supported). That category is still open to bootstrap programmers.
$setenv EXTRA_CFLAGS -g bash: setenv: command not found $ make |& tee makelog.txt bash: syntax error near unexpected token `&' $ tcsh % for i in *;do make -C $i clean;done for: Command not found. i: Undefined variable.
I wish this was true. However, which desktop you run directly limits which applications you can run.
How?? I've never seen a problem running Qt on Gnome, or Gtk on KDE, or any other combination.
I've got a Redhat 9 box right now. You can run KDE or Gnome, accessing the same applications in each, and it can be very challenging for an average user to even tell which particular desktop environment he happens to be running.
A corrolary to your statement might be "Applications written against the same API should not be made to look different."
That is, changable skins should not be allowed, because they remove clues that an app shares the same abilities as others.
However, I don't think that the current crop of Qt & Gtk apps have sufficiently standardized feature sets, even amoung a single API, to make their unified-presentation into something worth protecting. There are some freaky Qt programs, I'll tell you. Ksirc is one bad, example, but not the worst.
In this case, the need to go to a more pluggable architecture wasn't immediately obvious at the time, and neither was the solution (plug-ins and switching applications based on content type).
No, it's completely obvious. Given a statement of the problem, any normal software engineer at the time would've decided to switch applications based on content type.
Commercial products that handed off to a different helper program based on a content-type string date from 1988 or earlier. (Although back then, the "content-type" string was often just the final 3 characters of a filename. But it's the same idea)
Does anyone still use Active X on a web site? I can't remember any site asking for it in a long time.
The sites may be giving you a different page based on your browser-id.
Java and Flash (in various versions) are nearly the only plugins you'll see used on a modern website, but when IE users view them, the plugin is typically delivered over ActiveX.
If this legal-loophole worked, it'll just give Microsoft bigger incentive to hard-link Internet Explorer to a viewer for every datatype they want to support. I don't want to see that happen, but it's silly to imagine that there might be an data format whose viewer Microsoft cannot afford to buy outright.
In fact, Mozilla, or more generally, Open Source browsers could become the "rich" cousins, while proprietary browsers become the feature poor cousins. This would be very ironic.
In fact, Internet Explorer, or more generally, browsers from the richest company in the world could become the "rich" cousins, while smaller firms like Opera become feature-poor. This would be very expected.
The US military still gets primary use from it, at a level not available to civilians.
Welcome to the 21st century. Military and civilian GPS have been 100% equivalent since the Clinton administration.
The military retains the option to degrade or even deactivate civilian signals if they decide an active enemy is using GPS against them, but it has never been invoked.
How do you send messages to each other with knowledge of receipt? You can't. If I send the "Go" and you send the "OK", how do you know that I got the "OK"? I send an ACK. How do I know you got the "ACK"? You send me another ACK... and so on.
The "Two Armies" problem is a useful analogy for explaining some aspects of networking theory, but it's not relevant to email.
The ACKs which indicate if an email message was recieved are not themselves email messages- they're just TCP data. So the implied infinitely repetitive ACKs don't happen.
"Two Armies" is useful for understanding why TCP was implemented as it is- it demonstrates why the concepts of NACKs and sequence numbers are important for implementing a reliable protocol on top of an unreliable one. But from the perspective of email reliablity, that particular problem has already been solved in a lower-level protocol.
Because that's the only communications system the government has any business regulating.
Since the affordable installation of phone lines and fiberoptic cables was only possible by government application of eminent domain, the public (whose property was infringed) have a persistent right for the government to regulate those services on it's behalf.
However, the recent decision that VoIP services can be regulated as a phone company is completely wrong. The physical wires transmitting the packets are already subject to regulation- to impose any more control over them is "double dipping".
In other words, you should tax people for having children, to offset education costs?
Well, yes you should. But that's a totally separate topic (the US currently gives large payouts for having children).
However, the benefits of education apply not just to the student or her parents, but all of society. The most direct effect is reduced crime, and there's also a decent economic boost from the educated workforce.
In your own message, you both contradict yourself and admit ignorance.
Did this happen? Not really. I never saw any statistics on the number on smokers, so cannot say whether the number ever dropped. However, the revenue from cigarette tax actually dropped!
So you don't know whether it reduced smoking or not? I'll tell you then: It did.
The drop in revenue from cigarette taxes cannot be intrepreted as a "failure" of the program- it's a mark of success. Such a drop should be the final, victorious stage of any tax that was intended as a behavioral modifier, not a revenue enhancer.
That Cato & some Swedish politicians used revenue gain as their success criteria shows just how wrong their starting perspective was. The tax dollars you collect is not supposed to be the point!
Often governments will subvert the intent of "sin-tax" programs to boost revenue, rather than protect the public. That puts them in the dubious position of depending on continuation and growth in bad actions for their own profit.
in this Cato paper Patrick Fleenor takes a look at cigarette taxes in New York, which are higher than they are in many of the nearby states. He concludes that higher taxes
A biased group like Cato does not ever "conclude" anything. They predetermined the results before doing the research- they will ALWAYS say that taxes are bad, no matter what.
If you'd like a more scientific view of the issues, read any journal like Nicotine and Tobacco or the Journal of Public Health. You'll have to use a library's password to read the articles, but I can summarize in four words: "Cigarette taxes reduce smoking"
A well known fact which demonstrates a major design flaw.
The programmers were supposed to write a browser, but they decided to toss in an applicatin platform too.
To complain that their over-ambition degraded the performance of the web-browser that was the primary goal is completely valid. The extra work also held back release of usuable betas by almost two years.
That's why I said they wouldn't have to follow all the way through. Just go part of the way, make it an implicit threat- help them keep the price of owning chunks of Apple down, etc.
one apple is about the only semblence to a claim they aren't a monopoly that microsoft has got.
That's an issue I considered, but it's tough to guess how much this aspect really modifies their behavior. Whether or not the DoJ inspires any concern in MS might hinge on next year's presidential election (which in turn hinges on US infantry casualities...). Of course, they could call Linux a competitor also. That's a weaker claim in that Linux corporations aren't even as large as Apple, but stronger in that Apple doesn't actually compete in the OS market space (it's really a hardware company).
Two, microsoft owns a huge chunk of apple, and billg owns another large chunk.
Microsoft has long since sold it's famous Apple investment, which was never "huge" in any case. $150,000,000 is nothing to Microsoft. And it was cashed out by mid 2002.
Windows is so big, bloated and unstable because you have great binary compatibility. I can get Visicalc, one of the first spreadsheet programs for PCs, and run it under Windows XP.
That's insensible. The reason Visicalc works is because it's "statically linked". It doesn't depend on any external libraries to run. Statically linked Linux binaries will run on any Linux system (with the right CPU family). Dynamically linked Windows apps can easily get into "DLL hell". There are closed-source programs compiled for 2-year old versions of DirectX that no longer run on WindowsXP.
Linux developers don't usually like to release statically linked apps. They think it wastes space, and they're right. "Besides", the argument goes, "the needed libs are Free software, so you're allowed to obtain anything you need"
Wine does not in any way, shape, or form, emulate the x86 processor architecture.
Of course it doesn't. That's why I said "emulation doesn't imply imitating hardware". Because it DOESN'T. The acryonym-expansion for WINE is a lie. It emulates Microsoft Windows.
You can compile wine on an apple and it won't help one bit.
It'll help if you have some otherway to emulate x86, but still don't want to pay Microsoft(tm) $200 for Windows(r).
and they're the only ones who have a hope of getting all of the undocumented "features" of Windows right
VirtualPC doesn't need to know anything about Windows(r) features. VirtualPC emulates an Intel ("x86") computer, which you can then install a full (paid) copy of Windows on. One could also install Linux, FreeBSD, or other operating systems.
But now that Microsoft is selling VirtualPC, the above conditions might change. They will probably bundle a special Windows version, and discourage use of others. We might expect it'll become more difficult to install non-Microsoft OSes on top of the emulated environment.
MS obviously has an interest in stelling their software on Macs,
That's not obvious at all. They have 2 goals: sell software, and improve the ubiquity of Windows (which helps sell even more software later). Supporting users of Macs boosts the first goal, but not the second. Microsoft would be better off if there were only one seller of desktop computer OSes.
VirtualPC, in the nearterm, won't really encourage Mac users to buy MS software. The most popular MS programs (Word, Powerpoint, etc) are already sold in native Mac versions. MS has announced no plans to cancel development of Mac Office.
The real danger is the opposite of what you suggested- not that VirtualPC will work poorly with 3rd party software, but that it'll work too well. What if Microsoft uses VirtualPC to convince other software vendors (mainly Adobe) to downsize or eliminate their Mac software divisions? If companies can sell programs to Mac users without writing Mac code, why would they bother to program for two separate platforms?
Then, once Mac-specific development is good and dead, Microsoft can discontinue VirtualPC and kill Apple completely.
(Naturally, they have motivations to keep Apple alive... they wouldn't have to take the plan through to completetion. It could be just another club in their bargaining arsenal)
By every definition, WINE is an emulator. Nowhere does "emulator" imply that hardware is imitated.
To imitate the function of, as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system.
You're assuming the sig is intended as a release. I read it as a factual clarification- nothing more than a reminder of the law, current and probable.
I could write the first DOOM engine. I could probably even write something like Quake 2.
I could probably write something like Quake 2... oh wait, I've got the whole Quake2 source code right here! Nevermind.
If you're a small developer, the excuse of not having a basis to start from doesn't hold up. Carmack has graciously released his code to the public well before it became fully obselete.
As mentioned in other responses, the majority of the work for a new game is in graphic/level resources. The fact that your binaries are GPL won't hurt your commercial prospects very much- customers still have to pay to play the game experience you've designed.
(And if the code you do change is GPL, then you have the added potential benefit of leveraging changes made by other small game developers)
Games are more like books. All a game writer needs is a computer with some appropriate tools and a target platform set up for development.
By the definition of "game" as the authors of the original article were thinking about it, that isn't true. There has been a kind of fork in game development over the past 6-10 years.
In 1994 or so, "garage" games could still be popular. 10 talented guys working for 9 months could publish Doom or some other blockbuster title.
But since then, computers have gotten more and more storage space and output A/V quality. To make good use of all that power, you need large, high-quality artwork resources, and lots of them. (Look at how Everquest can't even run with 512 meg of RAM- yet it's graphics aren't top-quality). The cost to produce a game that can sit on a store shelf has ballooned to where it's comprable to Hollywood films.
No single author or small team can produce a game that'll earn money on the console or PC market.
Now, there has been a divergent path for game developers which has become more prominent in the past year. Web-based (flash, java, or small downloads of native binraries) have become popular and somewhat profitable (often advertising-supported). That category is still open to bootstrap programmers.
In 1997, Linus's .plan said "World Domination. Fast."
So he really doesn't limit ambitions at all.
It's more than 3 themes. They didn't only theme the popular toolkits, but also some specific applications like XMMS and Mozilla.
It's not like the command syntax is different.
$setenv EXTRA_CFLAGS -g
bash: setenv: command not found
$ make |& tee makelog.txt
bash: syntax error near unexpected token `&'
$ tcsh
% for i in *;do make -C $i clean;done
for: Command not found.
i: Undefined variable.
I wish this was true. However, which desktop you run directly limits which applications you can run.
How?? I've never seen a problem running Qt on Gnome, or Gtk on KDE, or any other combination.
I've got a Redhat 9 box right now. You can run KDE or Gnome, accessing the same applications in each, and it can be very challenging for an average user to even tell which particular desktop environment he happens to be running.
A corrolary to your statement might be "Applications written against the same API should not be made to look different."
That is, changable skins should not be allowed, because they remove clues that an app shares the same abilities as others.
However, I don't think that the current crop of Qt & Gtk apps have sufficiently standardized feature sets, even amoung a single API, to make their unified-presentation into something worth protecting. There are some freaky Qt programs, I'll tell you. Ksirc is one bad, example, but not the worst.
In this case, the need to go to a more pluggable architecture wasn't immediately obvious at the time, and neither was the solution (plug-ins and switching applications based on content type).
No, it's completely obvious. Given a statement of the problem, any normal software engineer at the time would've decided to switch applications based on content type.
Commercial products that handed off to a different helper program based on a content-type string date from 1988 or earlier. (Although back then, the "content-type" string was often just the final 3 characters of a filename. But it's the same idea)
Does anyone still use Active X on a web site? I can't remember any site asking for it in a long time.
The sites may be giving you a different page based on your browser-id.
Java and Flash (in various versions) are nearly the only plugins you'll see used on a modern website, but when IE users view them, the plugin is typically delivered over ActiveX.
If this legal-loophole worked, it'll just give Microsoft bigger incentive to hard-link Internet Explorer to a viewer for every datatype they want to support. I don't want to see that happen, but it's silly to imagine that there might be an data format whose viewer Microsoft cannot afford to buy outright.
In fact, Mozilla, or more generally, Open Source browsers could become the "rich" cousins, while proprietary browsers become the feature poor cousins. This would be very ironic.
In fact, Internet Explorer, or more generally, browsers from the richest company in the world could become the "rich" cousins, while smaller firms like Opera become feature-poor. This would be very expected.
Ok, let me get this straight... did you just make a slur on dumbasses by calling them "duh-masses"?
More likely it went from "the masses" -> "duh masses". Just try replacing either term into the original sentence and see why one sounds more in-place.
forced to provide a usable implimentation of your idea and then only that specific implimentation is to be under the patent.
If that were the case, then it would provide identical protection to a copyright, but only last 21 years instead of inifinity. So why bother?
The US military still gets primary use from it, at a level not available to civilians.
Welcome to the 21st century. Military and civilian GPS have been 100% equivalent since the Clinton administration.
The military retains the option to degrade or even deactivate civilian signals if they decide an active enemy is using GPS against them, but it has never been invoked.
How do you send messages to each other with knowledge of receipt? You can't. If I send the "Go" and you send the "OK", how do you know that I got the "OK"? I send an ACK. How do I know you got the "ACK"? You send me another ACK... and so on.
The "Two Armies" problem is a useful analogy for explaining some aspects of networking theory, but it's not relevant to email.
The ACKs which indicate if an email message was recieved are not themselves email messages- they're just TCP data. So the implied infinitely repetitive ACKs don't happen.
"Two Armies" is useful for understanding why TCP was implemented as it is- it demonstrates why the concepts of NACKs and sequence numbers are important for implementing a reliable protocol on top of an unreliable one. But from the perspective of email reliablity, that particular problem has already been solved in a lower-level protocol.
Because that's the only communications system the government has any business regulating.
Since the affordable installation of phone lines and fiberoptic cables was only possible by government application of eminent domain, the public (whose property was infringed) have a persistent right for the government to regulate those services on it's behalf.
However, the recent decision that VoIP services can be regulated as a phone company is completely wrong. The physical wires transmitting the packets are already subject to regulation- to impose any more control over them is "double dipping".
In other words, you should tax people for having children, to offset education costs?
Well, yes you should. But that's a totally separate topic (the US currently gives large payouts for having children).
However, the benefits of education apply not just to the student or her parents, but all of society. The most direct effect is reduced crime, and there's also a decent economic boost from the educated workforce.
In your own message, you both contradict yourself and admit ignorance.
Did this happen? Not really. I never saw any statistics on the number on smokers, so cannot say whether the number ever dropped. However, the revenue from cigarette tax actually dropped!
So you don't know whether it reduced smoking or not? I'll tell you then: It did.
The drop in revenue from cigarette taxes cannot be intrepreted as a "failure" of the program- it's a mark of success. Such a drop should be the final, victorious stage of any tax that was intended as a behavioral modifier, not a revenue enhancer.
That Cato & some Swedish politicians used revenue gain as their success criteria shows just how wrong their starting perspective was. The tax dollars you collect is not supposed to be the point!
Often governments will subvert the intent of "sin-tax" programs to boost revenue, rather than protect the public. That puts them in the dubious position of depending on continuation and growth in bad actions for their own profit.
in this Cato paper Patrick Fleenor takes a look at cigarette taxes in New York, which are higher than they are in many of the nearby states. He concludes that higher taxes
A biased group like Cato does not ever "conclude" anything. They predetermined the results before doing the research- they will ALWAYS say that taxes are bad, no matter what.
If you'd like a more scientific view of the issues, read any journal like Nicotine and Tobacco or the Journal of Public Health. You'll have to use a library's password to read the articles, but I can summarize in four words: "Cigarette taxes reduce smoking"
Mozilla is built as an application platform.
A well known fact which demonstrates a major design flaw.
The programmers were supposed to write a browser, but they decided to toss in an applicatin platform too.
To complain that their over-ambition degraded the performance of the web-browser that was the primary goal is completely valid. The extra work also held back release of usuable betas by almost two years.
That's why I said they wouldn't have to follow all the way through. Just go part of the way, make it an implicit threat- help them keep the price of owning chunks of Apple down, etc.
one apple is about the only semblence to a claim they aren't a monopoly that microsoft has got.
That's an issue I considered, but it's tough to guess how much this aspect really modifies their behavior. Whether or not the DoJ inspires any concern in MS might hinge on next year's presidential election (which in turn hinges on US infantry casualities...). Of course, they could call Linux a competitor also. That's a weaker claim in that Linux corporations aren't even as large as Apple, but stronger in that Apple doesn't actually compete in the OS market space (it's really a hardware company).
Two, microsoft owns a huge chunk of apple, and billg owns another large chunk.
Microsoft has long since sold it's famous Apple investment, which was never "huge" in any case. $150,000,000 is nothing to Microsoft. And it was cashed out by mid 2002.
Windows is so big, bloated and unstable because you have great binary compatibility. I can get Visicalc, one of the first spreadsheet programs for PCs, and run it under Windows XP.
That's insensible. The reason Visicalc works is because it's "statically linked". It doesn't depend on any external libraries to run. Statically linked Linux binaries will run on any Linux system (with the right CPU family). Dynamically linked Windows apps can easily get into "DLL hell". There are closed-source programs compiled for 2-year old versions of DirectX that no longer run on WindowsXP.
Linux developers don't usually like to release statically linked apps. They think it wastes space, and they're right. "Besides", the argument goes, "the needed libs are Free software, so you're allowed to obtain anything you need"
Know someone with . in their path?
/bin:/usr/bin:/usr/sbin::.
echo "#!/bin/rm -f" > cat; chmod a+x cat
% echo $PATH
% echo "#!/bin/rm -f" > cat; chmod a+x cat
% cat cat
#!/bin/rm -f
What's your point? Maybe you mean someone with . prepended to their path, not just in it.
Wine does not in any way, shape, or form, emulate the x86 processor architecture.
Of course it doesn't. That's why I said "emulation doesn't imply imitating hardware". Because it DOESN'T. The acryonym-expansion for WINE is a lie. It emulates Microsoft Windows.
You can compile wine on an apple and it won't help one bit.
It'll help if you have some other way to emulate x86, but still don't want to pay Microsoft(tm) $200 for Windows(r).
and they're the only ones who have a hope of getting all of the undocumented "features" of Windows right
VirtualPC doesn't need to know anything about Windows(r) features. VirtualPC emulates an Intel ("x86") computer, which you can then install a full (paid) copy of Windows on. One could also install Linux, FreeBSD, or other operating systems.
But now that Microsoft is selling VirtualPC, the above conditions might change. They will probably bundle a special Windows version, and discourage use of others. We might expect it'll become more difficult to install non-Microsoft OSes on top of the emulated environment.
MS obviously has an interest in stelling their software on Macs,
That's not obvious at all. They have 2 goals: sell software, and improve the ubiquity of Windows (which helps sell even more software later). Supporting users of Macs boosts the first goal, but not the second. Microsoft would be better off if there were only one seller of desktop computer OSes.
VirtualPC, in the nearterm, won't really encourage Mac users to buy MS software. The most popular MS programs (Word, Powerpoint, etc) are already sold in native Mac versions. MS has announced no plans to cancel development of Mac Office.
The real danger is the opposite of what you suggested- not that VirtualPC will work poorly with 3rd party software, but that it'll work too well. What if Microsoft uses VirtualPC to convince other software vendors (mainly Adobe) to downsize or eliminate their Mac software divisions? If companies can sell programs to Mac users without writing Mac code, why would they bother to program for two separate platforms?
Then, once Mac-specific development is good and dead, Microsoft can discontinue VirtualPC and kill Apple completely.
(Naturally, they have motivations to keep Apple alive... they wouldn't have to take the plan through to completetion. It could be just another club in their bargaining arsenal)
By every definition, WINE is an emulator. Nowhere does "emulator" imply that hardware is imitated.
To imitate the function of, as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system.