The key here is an "approved package mirror." Not debian.org but your own apt-cache that you keep track of packages with. The cache reduces network flow and increases control over your system as you allow or remove packages from said cache.
In theory what you'd want is some sort of "push" tech that forces packages upon the computers. In practice this is hard to implement securely and correctly. So an apt-get cron job will suffice nicely as a hack. Sure, if someone comprimises the apt-cache you're other ten can be hosed, but lets not forget the december incident.
Product dumping laws are protectionary. They're designed to protect domestic companies from price sharking competitors. Like if a foreign company started selling cars in America for 5 dollars, forcing the price so low that domestic firms have to shut down or face bleeding money. Traditionally, after the domestic firms shut down, the price spikes and the foreign company enjoys profits.
When there isn't a domestic product, dumping isn't affecting a domestic producer, and the laws typically get enforced. Of course, your milage may vary by country, as international law is hardly a concrete and predictable science.
I've been working on porting the Mr Cho's games to Linux, but its something of a pain. Even though he uses several technologies designed to make the process simple, there's a few gotchas. He uses a library called libBulletML that parses XML files for enemy firing patterns, and the latest two are written in D. So far I've only been able to get parsec47 working. Additionally, installation on a *nix machine is going to be problematic, since it just assumes the game has been placed in entirety in one directory.
That said, parsec is a pretty awesome game. It could use a few more improvements to solidify and use all the available ways to present information to players, but none of it matters much to anyone who wants to pick it up and enjoy for five minutes.
Interestingly enough, adding a -fomit-frame-pointer does not change the listing of options enabled. Perhaps its an alias for another option that was listed instead?
Not only does the constant and incremental card upgrade cycle alienate a ton of potential consumers, increasing power continually drains on developer's resources to provide polys to push.
I've been thinking for a while now that it isn't hw accelleration efficiency we need to improve on, but rather level designer and modelling techniques. Every iteration means more polygons have to be made up, which generally means more work for the artists-- higher poly models, higher resolution textures, smooth animation of characters, and lighting details are generally pushing the cost of development upwards with diminishing returns in sales, and very little influence with reviewers.
Nobody said that there was a majority share of DCC transfers happening legally. But its a far cry from "come on, execpt for one guy who maybe shares his folk music online, nobody uses it for anything but warez." I've recieved several high quality mods for halflife over DCC, and sent just as many. I've also used DCC as a convinent way of sending someone source code or an executable. Maybe all you use IRC for is music acquisition, but it certainly does have other users, which shouldn't be ignored. Just because there's a criminal majority, doesn't mean there's a need to spite legitimate use.
And its not like DCC is the only protocol involved in massive copyright infringement. Just like FTP, HTTP, KaZaa, Samba and bittorrent, DCC is a medium of transport, a method of transferring files. What files you choose to transfer is a human matter, not a technical one.
I know its not like slashdotters to follow a developing story by reading anything more than the usual snippets of any given article, but SCO has offered a shred of evidence. They've pointed at a few heavy server techniques that they just might have a point on. I have a feeling this case is going to help define for all software engineers just how much knowledge an employee can gain and apply elsewhere without violating copyright. How any company can go along and say "We looked at the source code and guarentee that all the software was owned by the submitter," given the implicit copyright on all code created.
For what its worth, Linux will go on, and I think SCO's tactics of suing users is in poor taste. The offending code, if any, can be removed or possibly changed and the majority of enterprise users will remain unaffected.
I guess you didn't read the little disclaimers at the bottom of yahoo. "Note: Text Twist is not compatible with Unix or Macintosh computers." Same goes for most the games that aren't board games. I haven't gotten the online card games to work under Linux, though I don't recall reading that it was specificaly not supported.
Maybe this is extrapolating too far, but online gameplay often suffers in the distribution of custom maps to play against eachother on. I'm told Tribes had a very small mapfile size, making custom maps easy to distribute from game server to clients. Contrast this with Halflife or counterstrike, with maps that sum up to a couple megs each. If there's twenty people on the map and none of them have the map, that's something like 100 megs transferred right there. And its certainly not instantaneous. I wonder if there's any applicability of the tech in this situation. I haven't had a chance to play the game yet, but I do recall FR-08.
Christ, the whole game fits in 96k. The size is a natural result entering a 96k competition. I'd imagine future releases might not meet the qualification, but remember, the entire game, complete with level textures and vertices is stored in those scant kilobytes.
The tradeoff involved wasn't executable size. Realistically, there's a lot of code within DirectX and whatever else was used. The tradeoff was execution time (esp at the beginning) and input size. I'd almost expect the executable to be smaller if it didn't have to have code to build textures.
Actually the coverage is pretty good at KSU. Nichols of course has it, and the engineering complex is laced with points. Of course, I find it ludicrous that anyone would actually.
Also, I don't remember signing a petition, but I do remember how on campus students were nearly monopolizing the internet pipe, such that the line was plateauing from 8 am to 8 pm. Since the implementation of p2p filtration this issue has largely vacated, and downloading from ocremix or debian updates typically move at 300 kpbs.
The IT staff in the basement are mostly concerned with the mainframes and the central router. The kind of people you want to talk with are upstairs, in ITAC or the head of CNS (or maybe resnet).
Actually, it don't think it helps anyone. In theory, you'd just pay for the five or ten channels you actually care about, but its likely the cable companies would just charge to make up for it. As for the the channels, it helps established channels branch out as well as remove a barrier to new channels. Of course, established companies have the upper hand in consumer awareness, since it would be difficult to advertise availability. Remember, Viacom is a large player who's grasp is difficult to avoid.
Additionally, who would subscribe to the Home Shopping Network? Should you be charged for local stations made available over cable? Or PBS? What about the city gov't access channel?
With very few exceptions any software publicly available for free is likely to suffer from the exact same problems, Open Source or not. I don't think this is an issue specific to Free Software, but rather software as a hobby. It just happens that there's a lot of Free Software being released as a hobbyist effort.
When Linux switched from ipchains to iptables, was there an inherant trade of security for usability? I hope not. You might point out that very few people use iptables or ipchains directly, which leads me to my real point.
GNU/linux is a collection of disparate software. There isn't a large entitity directing the manufacture and integration of the various tools hewn together to make what most people think of as "Linux." Usability means something above and beyond vim and bash. iptables is nice, but shorewall is usable. Sure, you can think of some trades a distribution might make ie users as root. But building an integrated system of management isn't nessecarily a bad thing, and done in a well thought out and managable way can actually help a hardened system. apt-get makes updating for security releases nearly painless, but it would be hard to argue that the added usability detracts from security. Sure, the servers could be comprimised, but so can source code. In the meantime, there's several ideas roaming about in certificying package authenticity.
Ogre Battle ran me 50 bucks. That's the biggest cart on the system too. Donno about Resident Evil, though.
On the other hand, its pretty easy for developers to see the disk space and wonder how to fill it. The answer thus far has been prerenders. Sometimes leading to sorry excuses for a "game," like Xenosaga. Hey, if people will pay 50 dollars for it, then more power to the artists behind it. But don't expect me to worship the unlimited gaming potential of optical media.
On the other hand, Square was routinely charging 70 dollars for their latest SNES title. Secret of Mana was still 60 a year after it came out. When the 64 came around, you could reasonalby expect to shell out 50 dollars for a new game on the 64. I didn't pay a whole lot of attention to the psx side, but I seem to recall that being about the same.
yea, but theres a ton of those... nuts. The code is available under something akin to the BSD and GPL, maybe someone should place a sourceforge project, and submit to happypenguin for game of the month development!
Ever installed the D compiler? Me either. From what I can tell, support is somewhat minimal for it. In the time D has been around, C# has gone from concept to deployment to the world at large.
I'll stick with planet.debian.net. The people aggregated there have to deal with the the public and software at the same time. There's people working on the installer, the GUI people, and an embedded guy. Every one of these people actually maintains software for the Debian project, not just someone who's paid to be a "Technical Evangelist."
Slashdot Mirror
The key here is an "approved package mirror." Not debian.org but your own apt-cache that you keep track of packages with. The cache reduces network flow and increases control over your system as you allow or remove packages from said cache.
In theory what you'd want is some sort of "push" tech that forces packages upon the computers. In practice this is hard to implement securely and correctly. So an apt-get cron job will suffice nicely as a hack. Sure, if someone comprimises the apt-cache you're other ten can be hosed, but lets not forget the december incident.
Product dumping laws are protectionary. They're designed to protect domestic companies from price sharking competitors. Like if a foreign company started selling cars in America for 5 dollars, forcing the price so low that domestic firms have to shut down or face bleeding money. Traditionally, after the domestic firms shut down, the price spikes and the foreign company enjoys profits.
When there isn't a domestic product, dumping isn't affecting a domestic producer, and the laws typically get enforced. Of course, your milage may vary by country, as international law is hardly a concrete and predictable science.
I've been working on porting the Mr Cho's games to Linux, but its something of a pain. Even though he uses several technologies designed to make the process simple, there's a few gotchas. He uses a library called libBulletML that parses XML files for enemy firing patterns, and the latest two are written in D. So far I've only been able to get parsec47 working. Additionally, installation on a *nix machine is going to be problematic, since it just assumes the game has been placed in entirety in one directory.
That said, parsec is a pretty awesome game. It could use a few more improvements to solidify and use all the available ways to present information to players, but none of it matters much to anyone who wants to pick it up and enjoy for five minutes.
The day loans became a legitamate way to do business. Obligations to repay aren't optional you know.
Interestingly enough, adding a -fomit-frame-pointer does not change the listing of options enabled. Perhaps its an alias for another option that was listed instead?
Not only does the constant and incremental card upgrade cycle alienate a ton of potential consumers, increasing power continually drains on developer's resources to provide polys to push.
I've been thinking for a while now that it isn't hw accelleration efficiency we need to improve on, but rather level designer and modelling techniques. Every iteration means more polygons have to be made up, which generally means more work for the artists-- higher poly models, higher resolution textures, smooth animation of characters, and lighting details are generally pushing the cost of development upwards with diminishing returns in sales, and very little influence with reviewers.
Nobody said that there was a majority share of DCC transfers happening legally. But its a far cry from "come on, execpt for one guy who maybe shares his folk music online, nobody uses it for anything but warez." I've recieved several high quality mods for halflife over DCC, and sent just as many. I've also used DCC as a convinent way of sending someone source code or an executable. Maybe all you use IRC for is music acquisition, but it certainly does have other users, which shouldn't be ignored. Just because there's a criminal majority, doesn't mean there's a need to spite legitimate use.
And its not like DCC is the only protocol involved in massive copyright infringement. Just like FTP, HTTP, KaZaa, Samba and bittorrent, DCC is a medium of transport, a method of transferring files. What files you choose to transfer is a human matter, not a technical one.
More like how the U.S. Attorney General's office would educate the RIAA on amnesty.
I know its not like slashdotters to follow a developing story by reading anything more than the usual snippets of any given article, but SCO has offered a shred of evidence. They've pointed at a few heavy server techniques that they just might have a point on. I have a feeling this case is going to help define for all software engineers just how much knowledge an employee can gain and apply elsewhere without violating copyright. How any company can go along and say "We looked at the source code and guarentee that all the software was owned by the submitter," given the implicit copyright on all code created.
For what its worth, Linux will go on, and I think SCO's tactics of suing users is in poor taste. The offending code, if any, can be removed or possibly changed and the majority of enterprise users will remain unaffected.
People with 10+ years experience tend too overvalue their skills and experience ;)
I guess you didn't read the little disclaimers at the bottom of yahoo. "Note: Text Twist is not compatible with Unix or Macintosh computers." Same goes for most the games that aren't board games. I haven't gotten the online card games to work under Linux, though I don't recall reading that it was specificaly not supported.
Multiplatform, easy to learn, short rounds, and offers in game communication. Servers exist for both Linux and Windows.
Maybe this is extrapolating too far, but online gameplay often suffers in the distribution of custom maps to play against eachother on. I'm told Tribes had a very small mapfile size, making custom maps easy to distribute from game server to clients.
Contrast this with Halflife or counterstrike, with maps that sum up to a couple megs each. If there's twenty people on the map and none of them have the map, that's something like 100 megs transferred right there. And its certainly not instantaneous.
I wonder if there's any applicability of the tech in this situation. I haven't had a chance to play the game yet, but I do recall FR-08.
Christ, the whole game fits in 96k. The size is a natural result entering a 96k competition. I'd imagine future releases might not meet the qualification, but remember, the entire game, complete with level textures and vertices is stored in those scant kilobytes.
The tradeoff involved wasn't executable size. Realistically, there's a lot of code within DirectX and whatever else was used. The tradeoff was execution time (esp at the beginning) and input size. I'd almost expect the executable to be smaller if it didn't have to have code to build textures.
"I was a video game reviewer for a zine,"
Oh, well there's a hard to come by credential!
Actually the coverage is pretty good at KSU. Nichols of course has it, and the engineering complex is laced with points. Of course, I find it ludicrous that anyone would actually.
Also, I don't remember signing a petition, but I do remember how on campus students were nearly monopolizing the internet pipe, such that the line was plateauing from 8 am to 8 pm. Since the implementation of p2p filtration this issue has largely vacated, and downloading from ocremix or debian updates typically move at 300 kpbs.
The IT staff in the basement are mostly concerned with the mainframes and the central router. The kind of people you want to talk with are upstairs, in ITAC or the head of CNS (or maybe resnet).
Actually, it don't think it helps anyone. In theory, you'd just pay for the five or ten channels you actually care about, but its likely the cable companies would just charge to make up for it. As for the the channels, it helps established channels branch out as well as remove a barrier to new channels. Of course, established companies have the upper hand in consumer awareness, since it would be difficult to advertise availability. Remember, Viacom is a large player who's grasp is difficult to avoid.
Additionally, who would subscribe to the Home Shopping Network? Should you be charged for local stations made available over cable? Or PBS? What about the city gov't access channel?
"You get what you pay for."
With very few exceptions any software publicly available for free is likely to suffer from the exact same problems, Open Source or not. I don't think this is an issue specific to Free Software, but rather software as a hobby. It just happens that there's a lot of Free Software being released as a hobbyist effort.
When Linux switched from ipchains to iptables, was there an inherant trade of security for usability? I hope not. You might point out that very few people use iptables or ipchains directly, which leads me to my real point.
GNU/linux is a collection of disparate software. There isn't a large entitity directing the manufacture and integration of the various tools hewn together to make what most people think of as "Linux." Usability means something above and beyond vim and bash. iptables is nice, but shorewall is usable. Sure, you can think of some trades a distribution might make ie users as root. But building an integrated system of management isn't nessecarily a bad thing, and done in a well thought out and managable way can actually help a hardened system. apt-get makes updating for security releases nearly painless, but it would be hard to argue that the added usability detracts from security. Sure, the servers could be comprimised, but so can source code. In the meantime, there's several ideas roaming about in certificying package authenticity.
Ogre Battle ran me 50 bucks. That's the biggest cart on the system too. Donno about Resident Evil, though.
On the other hand, its pretty easy for developers to see the disk space and wonder how to fill it. The answer thus far has been prerenders. Sometimes leading to sorry excuses for a "game," like Xenosaga. Hey, if people will pay 50 dollars for it, then more power to the artists behind it. But don't expect me to worship the unlimited gaming potential of optical media.
On the other hand, Square was routinely charging 70 dollars for their latest SNES title. Secret of Mana was still 60 a year after it came out. When the 64 came around, you could reasonalby expect to shell out 50 dollars for a new game on the 64. I didn't pay a whole lot of attention to the psx side, but I seem to recall that being about the same.
yea, but theres a ton of those... nuts. The code is available under something akin to the BSD and GPL, maybe someone should place a sourceforge project, and submit to happypenguin for game of the month development!
How on earth did you get that to compile? I'm getting tons of float-int errors!
Ever installed the D compiler? Me either. From what I can tell, support is somewhat minimal for it. In the time D has been around, C# has gone from concept to deployment to the world at large.
I'll stick with planet.debian.net. The people aggregated there have to deal with the the public and software at the same time. There's people working on the installer, the GUI people, and an embedded guy. Every one of these people actually maintains software for the Debian project, not just someone who's paid to be a "Technical Evangelist."