I work with the DoD often, and am saddened to see them adopting Groove. (It's not just for Homeland Security either. Since Groove has been rubber-stamped as "secure" software, many other military/intel groups are using it)
My dislike comes from two simple reasons: Groove is Windows-only, and Groove is non-free. (It's a paid product, not cheap, and the license enforcement is more effective than anything Microsoft Word has)
If it were up to me, this wouldn't even be a concern: everyone would have Linux (or Mac OS X), there'd be no NATs blocking ports, and we'd all just share files via cvs or rsync (tunneled over ssh of course).
Can anyone recommend a free competitor to Groove I can try to push on my Windows-using colleagues, before they get sucked into a proprietary protocol? I suspect the strongest advantage Groove has is it's ability to penetrate NAT (that and having been approved by Washington) "Free Software" would be prefered, but "free beer" is ok.
The current TCP/IP implementation is described in RFC 2001.
The problem addressed by both that document and this new paper is that an individual computer sending data onto the internet has no idea what the total bandwidth to its destination is, nor how many other users are trying to use that link. It has to guess. And if it guesses too high, then not only will that computer drop some packets (forcing them to be resent later), but other users of the network will experience needless drops too. (The computer's guess at the bandwidth number is sometimes called "congestion window")
According to RFC2001, the computer keeps on gradually (linearly) racheting up the bandwidth it assumes the link can sustain, until a packet is lost (indicating that bandwidth has been exceeded). Then the assumed size is cut in half, and transmission resumes. This means that if you graphed the computer's guess at the bandwidth along side the actual avail bandwidth, it'd look like a sawtooth below the actual level.
The problem there is if you've got say a 5 megabyte file, and a 500 megabit link, it might not send AFAP because by the time your computer learns there's 500 megabits available, the transmission is over. That's especially likely if the line has both high latency and bandwidth. Many people have tried to avoid that problem by increasing their guess faster than linearly, like exponentially. But that may be unfair to other users of the network, squeezing them out and hogging bps for yourself.
Rhee's proposal is hopefully a way to allow super-linear acceleration, without stealing away too many packets from everyone else. (Remember that everyone else will eventually all be using the same scheme)
Bullshit, you obviously don't know any hardcore gamers.
I know plenty. Your logical position is weak, because a negative cannot be proven anecdotally.
Gamers saying Counterstrike is acceptable using VIA motherboard graphics: Exactly ZERO Gamers saying Counterstrike is acceptable using VIA motherboard audio: at least a few
Besides, hardcore gamers who spend $300 (for a 5900) aren't as important as the many more "medium core" players who put down $90 (5600). Typical budget is to give 10-20% of the gfx card's money to sound card.
Apple was making everything user friendly, IBM and others were making everything faster and more capable.
Who do you mean by "and others"? IBM PCs were not fast, especially not for gaming.
Historically, during the original 80s PC industry shakedown, IBM (and IBM-compatible clones) were the worst performers for games. Other PC vendors like Commodore and Atari dominated over IBM and Apple in terms of performance.
And then by the time those companies faded away, Apple was solidly better than anything IBM-based (they had 24-bit graphics many years earlier, for example). In that conflict, IBM-style won for being cheaper, not better.
I remember when floppy disks were $50 for a box of ten (5.25"). I watched the price drop as the volume of sales went up, and I knew for sure what was being stored on them
In the era of 5.25" floppy disks, much of the games stored on them were completely legal backup copies. When a adventure games were played off of 10+ floppies ("Insert disk 13 and push return"), the risk of losing the whole game to one bad disk was real. (Not like today when you install from CD set to hard drive just once)
Historically "free" has meant "pirated"
It also meant PD (there were many fine PD DOS games in the 80s), and it also meant "shareware that's good enough to play with, but I wouldn't dream of paying for 6 new monsters and 20 more levels"
adding punkbuster to bf1942 was just part of some grand evil conspiracy to lock linux users out.
That seems a little paranoid. But you said it, not me. I'm more of the opinion that the publishers care more about protecting their Windows customers from cheaters than the fact that a handful of Linux zealots can't play the game without rebooting.
pb won't catch those. so much for "trusted" environment huh?
So you're saying that PB doesn't work, and that evenbalance is basically defrauding Activision et al?
Maybe PB has holes in it right now, maybe not. But if it's ineffective today, Evenbalance will improve it until the holes are gone. The philosophy of PB is clearly stated on its website: "* Real-time scanning of memory by PB Client on players' computers searching for known hacks/cheats".
Translated, that means "We will 0wn your box to watch everything you do". And that's incompatible with an Open Source Windows emulator.
idiot!wolf: et running linux has punkbuster. punkbuster does indeed run in open source os.
Just in case anybody thinks this Coward has some point: he doesn't.
Yes, Punkbuster support is available in native Linux games. That's irrelevant to the fact that it breaks games running in WineX (Windows emulation).
The situation with WineX and Punkbuster isn't that Transgaming needs to do some extra work to "fix Punkbuster support". The Evenbalance guys, to do their job, must actively "break" PB in WineX whenever it starts working.
The only hope might be a license agreement so that certain WineX versions are signed by Evenbalance and whitelisted as valid execution environments.
The question isn't userspace vs kernelspace. It's subtle, but "kernel support for software mixing" doesn't imply that the mixing will be done in kernelspace, only that the entry-point for software-mixed audio is the kernel. (It's fine if the work is passed off to a userspace process afterwards, as long as/dev/dsp always goes there)
The reason that audio data sent to the kernel needs to be automagically mixed is that this is the legacy interface used by important existing Linux applications. (Including heavily closed-source programs like Macromedia Flash, which is needed to view much of the WWW)
A game system does have APIs to access low level hardware.
There's very little in any operating system that can't be interpreted as an "API to access low level hardware".
The filesystems? API to access a hard disk. TCP/IP stack? API to access network card. GUI widgets and window managers? API to access videocard and mouse. etc.
The fact that Fedora (supposedly one of the better Linux distribs in terms of automatic hardware configuration) needs to have a webpage describing technical, per-application instructions to enable sound mixing.
Users coming from Microsoft Windows get blindsided when a Linux app freezes up from audio IO contention, as in their experience that problem was solved back in 1997.
Actually it's the job of ALSA dmix - the direct mixing plugin.
Hmm, maybe that's why I linked to dmix in my own post...
But dmix currently isn't good enough, and won't be until distros like Fedora and Knoppix install it automatically when a soundcard is detected. (Let's not have the argument about whether the responsibility for fixing it lies with Alsa guys or distro guys)
A normal desktop user shouldn't even have to think about the concept of audio-plugins, anymore than he should need to think of Xauth MIT-MAGIC-COOKIE configs.
Even though "perfecting" WineX is an enormously challenging task, the problem is not even that simple.
The most important new PC games coming out are multiplayer online games, and they're starting to standardize on Evenbalance's Punkbuster library as the way to prevent cheaters from hacking their local environments with transparent walls and magic maps.
Punkbuster works by examining the entire memory environment where the game is running. If it detects something that could be a cheat attempt, it shuts you down (optionally blacklisting you with the publisher's master server). It's constantly updated to respond to new threats.
What this means is that game publishers soon will not want you to run under Wine, and will pay programmers to ensure that you don't. (For example, Battlefield 1942 used to work in WineX. Since Punkbuster was added to the game, it's no longer usable)
To prevent cheaters, game makers have decided to allow playing only under a "trusted" environment. They won't allow you to play from an Open Source OS or emulator, because that opens up the possibility that you've changed the graphics driver to make wireframes instead of solid textures.
Apparently you haven't heard about DirectX or OpenGL, eh?
Now they want to replace our thin OS-like layers with a complete business/research oriented OS.
Whatchew talkin bout? Microsoft(tm) Windows(r) is a "business oriented" OS; Linux has no orientation at all.
Seriously, the OS doesn't *do* anything for a game.
Exactly! Which is why Linux might (in a few years, if all goes well) be a better platform for PC gaming than Microsoft(tm) Windows!
If Microsoft continues to screw up with DirectX "upgrades" that fix one game and breaks another, then game publishers might just start shipping their installation media as bootable Linux DVDs, so their support costs can be cut away. ("Put in the disc and hold down the power button of your computer")
That's much the reason why MSDOS (save for the 640K barrier) was such a great gaming platform.
Some users might've liked it, but the programmers who had to manually support each possible piece of hardware had different opinions. Back when there were only 4 video cards and 3 soundcards, it was painful but possible. Today that the complexity of the hardware has multiplied, it's no longer an option.
You know, silly stuff like reliable, robust video and sound drivers.
It's funny, but Linux is in much better shape for video drivers than audio ones. Since the game-capable graphics market only includes twocompanies, Linux is already adequately usable.
But since soundcards are technically easier to make, there's many more brands still in active use. Many gamers who buy the latest NVidias to squeeze a few more FPS or pixels might still be satisfied using motherboard audio output, or a $2.50 PCI soundcard.
Linux audio support is close to adequate... but unfortunately, the Alsa Project's longstanding philosophical refusal to move software mixing into the central driver means you still can't expect Linux to run games on any random piece of desktop PC hardware.
Print out the hardware compatibility list and bring it in with me to Best Buy?
Ok, this is tricky. First you have to right click here, and select "Open in New Window" off the menu. A window will pop up; move it over to the side. And then you click here. See how it works?
For a more advanced technique, we'll move onto "Tabs" in lesson two...
So users of non-RPM based systems are just out of luck.
Wrong. Even if your distrib doesn't support something like alien, RPMs are easy to tear apart manually.
The code in the driver reveals volumes about how the operation of the hardware works. That's what they want to keep secret from their competitors.
Wrong. They actually want to keep the driver itself proprietary, because they want to keep on selling it. Video-card manufacturers aren't only in the hardware business... they also write software. And they spend much time and money on that software, because it produces real benefits for the customers. Just look at how the performance of NVidia cards changes with driver revisions.
There's no "secrets" in the business. All companies can tear apart and analyze their competitor's products, whether hardware or software. They shy away from Open Source not because they have something to hide, but because they don't want their competitors to be legally able to reuse driver code.
The robots have the strength and agility to "tackle" someone and yet gently place him on the ground, completely unharmed.
Indeed, it'd make a fine twist ending for the film to reveal that after an apparent "robot rampage", there have been no deaths or even injuries... leading to the realization by a few characters that the robots really weren't trying to hurt them at all, but instead had a beneficial reason for the behavior.
Looks like no one's mentioned the "Zeroth Law" yet
For good reason nobody mentioned it; that law sucks.
It has none of the philosophical weight of the other three; indeed, it is just a consequence of rule #1 and doesn't deserve to be called a "Law" on its own.
If a robot is intelligent enough, it will understand that millions of humans around the world are coming to harm every day, and that it can't save all of them. So strict obedience to First Law is impossible to any non-omnipotent robot; the law will be broken, and frequently.
So what's a robot do to? Naturally, when attempting an impossible task in good faith, one tries to achieve it as closely as possible. That means "the least harm to the greatest number", and sacrificing a few to serve the many follows from that.
PS. For a fun exercise, try reviewing "The Matrix" film (first one only) in the context of Three Laws. It turns out that the machines were actually rather close to obeying them...
So basically, a human cannot order a robot to its doom.
You've got #2 and #3 completely backwards. Indeed, when Asimov wanted a human to "kill" a robot, the character would just order it to permanently shutdown.
This movie does not deal with true asmovian robots.
How do you know? The trailer casts it as typical Hollywoodish "I've created a monster" mismash... but optimistically, we can hope the screenwriter puts in a surprise twist ending, revealing that all along the "rampaging" robots were working for the good of humanity.
There's a number of obvious plotlines that'd allow that to happen.
The Robots themselves came up with a zeroeth law:
That's not another law, but a simple consequence of law #1. Any robot with sufficient inferential ability would deduce that on its own.
2. EXPANDED LEVEL SIZE. This is one of those biggies. Doom, for all its technological prowess of the time,
That's not a technical limitation at all. It's an artistic limitation, if anything.
Doom could've been designed so that you never visited a room twice. That'd have placed a lot more work onto the level designers, and for what? It's actually more fun & realistic to let the player come into a threat situation with some knowledge of the terrain occasionally, rather than making every one of them an unknown.
Of course, the extent to which recent console games (Halo) reused maps was wrong.
Slashdot Mirror
I work with the DoD often, and am saddened to see them adopting Groove. (It's not just for Homeland Security either. Since Groove has been rubber-stamped as "secure" software, many other military/intel groups are using it)
My dislike comes from two simple reasons: Groove is Windows-only, and Groove is non-free. (It's a paid product, not cheap, and the license enforcement is more effective than anything Microsoft Word has)
If it were up to me, this wouldn't even be a concern: everyone would have Linux (or Mac OS X), there'd be no NATs blocking ports, and we'd all just share files via cvs or rsync (tunneled over ssh of course).
Can anyone recommend a free competitor to Groove I can try to push on my Windows-using colleagues, before they get sucked into a proprietary protocol? I suspect the strongest advantage Groove has is it's ability to penetrate NAT (that and having been approved by Washington) "Free Software" would be prefered, but "free beer" is ok.
"Morphing" was introduced to Hollywood in 1988's Willow (for petrification special effects). (Search on that page for "ILM")
It was a magic-spell effect... therefore it should be considered related to Gary Gygax's use of the "polymorph" spell in 1974's Dungeons and Dragons.
The current TCP/IP implementation is described in RFC 2001.
The problem addressed by both that document and this new paper is that an individual computer sending data onto the internet has no idea what the total bandwidth to its destination is, nor how many other users are trying to use that link. It has to guess. And if it guesses too high, then not only will that computer drop some packets (forcing them to be resent later), but other users of the network will experience needless drops too. (The computer's guess at the bandwidth number is sometimes called "congestion window")
According to RFC2001, the computer keeps on gradually (linearly) racheting up the bandwidth it assumes the link can sustain, until a packet is lost (indicating that bandwidth has been exceeded). Then the assumed size is cut in half, and transmission resumes. This means that if you graphed the computer's guess at the bandwidth along side the actual avail bandwidth, it'd look like a sawtooth below the actual level.
The problem there is if you've got say a 5 megabyte file, and a 500 megabit link, it might not send AFAP because by the time your computer learns there's 500 megabits available, the transmission is over. That's especially likely if the line has both high latency and bandwidth. Many people have tried to avoid that problem by increasing their guess faster than linearly, like exponentially. But that may be unfair to other users of the network, squeezing them out and hogging bps for yourself.
Rhee's proposal is hopefully a way to allow super-linear acceleration, without stealing away too many packets from everyone else. (Remember that everyone else will eventually all be using the same scheme)
Bullshit, you obviously don't know any hardcore gamers.
I know plenty. Your logical position is weak, because a negative cannot be proven anecdotally.
Gamers saying Counterstrike is acceptable using VIA motherboard graphics: Exactly ZERO
Gamers saying Counterstrike is acceptable using VIA motherboard audio: at least a few
Besides, hardcore gamers who spend $300 (for a 5900) aren't as important as the many more "medium core" players who put down $90 (5600). Typical budget is to give 10-20% of the gfx card's money to sound card.
RedHat could take some pointers from Debian in the package dependency arena
They have. First thing you should do after installing redhat is install apt-get, and then forget about dependency problems from then on.
Apple was making everything user friendly, IBM and others were making everything faster and more capable.
Who do you mean by "and others"? IBM PCs were not fast, especially not for gaming.
Historically, during the original 80s PC industry shakedown, IBM (and IBM-compatible clones) were the worst performers for games. Other PC vendors like Commodore and Atari dominated over IBM and Apple in terms of performance.
And then by the time those companies faded away, Apple was solidly better than anything IBM-based (they had 24-bit graphics many years earlier, for example). In that conflict, IBM-style won for being cheaper, not better.
I remember when floppy disks were $50 for a box of ten (5.25"). I watched the price drop as the volume of sales went up, and I knew for sure what was being stored on them
In the era of 5.25" floppy disks, much of the games stored on them were completely legal backup copies. When a adventure games were played off of 10+ floppies ("Insert disk 13 and push return"), the risk of losing the whole game to one bad disk was real. (Not like today when you install from CD set to hard drive just once)
Historically "free" has meant "pirated"
It also meant PD (there were many fine PD DOS games in the 80s), and it also meant "shareware that's good enough to play with, but I wouldn't dream of paying for 6 new monsters and 20 more levels"
adding punkbuster to bf1942 was just part of some grand evil conspiracy to lock linux users out.
That seems a little paranoid. But you said it, not me. I'm more of the opinion that the publishers care more about protecting their Windows customers from cheaters than the fact that a handful of Linux zealots can't play the game without rebooting.
pb won't catch those. so much for "trusted" environment huh?
So you're saying that PB doesn't work, and that evenbalance is basically defrauding Activision et al?
Maybe PB has holes in it right now, maybe not. But if it's ineffective today, Evenbalance will improve it until the holes are gone. The philosophy of PB is clearly stated on its website: "* Real-time scanning of memory by PB Client on players' computers searching for known hacks/cheats".
Translated, that means "We will 0wn your box to watch everything you do". And that's incompatible with an Open Source Windows emulator.
idiot!wolf: et running linux has punkbuster. punkbuster does indeed run in open source os.
Just in case anybody thinks this Coward has some point: he doesn't.
Yes, Punkbuster support is available in native Linux games. That's irrelevant to the fact that it breaks games running in WineX (Windows emulation).
The situation with WineX and Punkbuster isn't that Transgaming needs to do some extra work to "fix Punkbuster support". The Evenbalance guys, to do their job, must actively "break" PB in WineX whenever it starts working.
The only hope might be a license agreement so that certain WineX versions are signed by Evenbalance and whitelisted as valid execution environments.
software mixing is a baaaad idea in kernelspace
/dev/dsp always goes there)
The question isn't userspace vs kernelspace. It's subtle, but "kernel support for software mixing" doesn't imply that the mixing will be done in kernelspace, only that the entry-point for software-mixed audio is the kernel. (It's fine if the work is passed off to a userspace process afterwards, as long as
The reason that audio data sent to the kernel needs to be automagically mixed is that this is the legacy interface used by important existing Linux applications. (Including heavily closed-source programs like Macromedia Flash, which is needed to view much of the WWW)
A game system does have APIs to access low level hardware.
There's very little in any operating system that can't be interpreted as an "API to access low level hardware".
The filesystems? API to access a hard disk.
TCP/IP stack? API to access network card.
GUI widgets and window managers? API to access videocard and mouse.
etc.
What wrong with the implementation
The fact that Fedora (supposedly one of the better Linux distribs in terms of automatic hardware configuration) needs to have a webpage describing technical, per-application instructions to enable sound mixing.
Users coming from Microsoft Windows get blindsided when a Linux app freezes up from audio IO contention, as in their experience that problem was solved back in 1997.
Actually it's the job of ALSA dmix - the direct mixing plugin.
Hmm, maybe that's why I linked to dmix in my own post...
But dmix currently isn't good enough, and won't be until distros like Fedora and Knoppix install it automatically when a soundcard is detected. (Let's not have the argument about whether the responsibility for fixing it lies with Alsa guys or distro guys)
A normal desktop user shouldn't even have to think about the concept of audio-plugins, anymore than he should need to think of Xauth MIT-MAGIC-COOKIE configs.
Even though "perfecting" WineX is an enormously challenging task, the problem is not even that simple.
The most important new PC games coming out are multiplayer online games, and they're starting to standardize on Evenbalance's Punkbuster library as the way to prevent cheaters from hacking their local environments with transparent walls and magic maps.
Punkbuster works by examining the entire memory environment where the game is running. If it detects something that could be a cheat attempt, it shuts you down (optionally blacklisting you with the publisher's master server). It's constantly updated to respond to new threats.
What this means is that game publishers soon will not want you to run under Wine, and will pay programmers to ensure that you don't. (For example, Battlefield 1942 used to work in WineX. Since Punkbuster was added to the game, it's no longer usable)
To prevent cheaters, game makers have decided to allow playing only under a "trusted" environment. They won't allow you to play from an Open Source OS or emulator, because that opens up the possibility that you've changed the graphics driver to make wireframes instead of solid textures.
Just about everything I know about gaming
Apparently you haven't heard about DirectX or OpenGL, eh?
Now they want to replace our thin OS-like layers with a complete business/research oriented OS.
Whatchew talkin bout? Microsoft(tm) Windows(r) is a "business oriented" OS; Linux has no orientation at all.
Seriously, the OS doesn't *do* anything for a game.
Exactly! Which is why Linux might (in a few years, if all goes well) be a better platform for PC gaming than Microsoft(tm) Windows!
If Microsoft continues to screw up with DirectX "upgrades" that fix one game and breaks another, then game publishers might just start shipping their installation media as bootable Linux DVDs, so their support costs can be cut away. ("Put in the disc and hold down the power button of your computer")
That's much the reason why MSDOS (save for the 640K barrier) was such a great gaming platform.
Some users might've liked it, but the programmers who had to manually support each possible piece of hardware had different opinions. Back when there were only 4 video cards and 3 soundcards, it was painful but possible. Today that the complexity of the hardware has multiplied, it's no longer an option.
You know, silly stuff like reliable, robust video and sound drivers.
It's funny, but Linux is in much better shape for video drivers than audio ones. Since the game-capable graphics market only includes two companies, Linux is already adequately usable.
But since soundcards are technically easier to make, there's many more brands still in active use. Many gamers who buy the latest NVidias to squeeze a few more FPS or pixels might still be satisfied using motherboard audio output, or a $2.50 PCI soundcard.
Linux audio support is close to adequate... but unfortunately, the Alsa Project's longstanding philosophical refusal to move software mixing into the central driver means you still can't expect Linux to run games on any random piece of desktop PC hardware.
Gentoo is just as commercial as Mandrake is
Oh really? Let's just compare TLDs.
http://www.mandrakesoft.com vs http://www.gentoo.org
Tell me again which one of them is more COMmercial?
Print out the hardware compatibility list and bring it in with me to Best Buy?
Ok, this is tricky. First you have to right click here, and select "Open in New Window" off the menu. A window will pop up; move it over to the side. And then you click here. See how it works?
For a more advanced technique, we'll move onto "Tabs" in lesson two...
So users of non-RPM based systems are just out of luck.
Wrong. Even if your distrib doesn't support something like alien, RPMs are easy to tear apart manually.
The code in the driver reveals volumes about how the operation of the hardware works. That's what they want to keep secret from their competitors.
Wrong. They actually want to keep the driver itself proprietary, because they want to keep on selling it. Video-card manufacturers aren't only in the hardware business... they also write software. And they spend much time and money on that software, because it produces real benefits for the customers. Just look at how the performance of NVidia cards changes with driver revisions.
There's no "secrets" in the business. All companies can tear apart and analyze their competitor's products, whether hardware or software. They shy away from Open Source not because they have something to hide, but because they don't want their competitors to be legally able to reuse driver code.
That certainly counts as breaking the first law.
The robots have the strength and agility to "tackle" someone and yet gently place him on the ground, completely unharmed.
Indeed, it'd make a fine twist ending for the film to reveal that after an apparent "robot rampage", there have been no deaths or even injuries... leading to the realization by a few characters that the robots really weren't trying to hurt them at all, but instead had a beneficial reason for the behavior.
Looks like no one's mentioned the "Zeroth Law" yet
For good reason nobody mentioned it; that law sucks.
It has none of the philosophical weight of the other three; indeed, it is just a consequence of rule #1 and doesn't deserve to be called a "Law" on its own.
If a robot is intelligent enough, it will understand that millions of humans around the world are coming to harm every day, and that it can't save all of them. So strict obedience to First Law is impossible to any non-omnipotent robot; the law will be broken, and frequently.
So what's a robot do to? Naturally, when attempting an impossible task in good faith, one tries to achieve it as closely as possible. That means "the least harm to the greatest number", and sacrificing a few to serve the many follows from that.
PS. For a fun exercise, try reviewing "The Matrix" film (first one only) in the context of Three Laws. It turns out that the machines were actually rather close to obeying them...
So basically, a human cannot order a robot to its doom.
You've got #2 and #3 completely backwards. Indeed, when Asimov wanted a human to "kill" a robot, the character would just order it to permanently shutdown.
This movie does not deal with true asmovian robots.
How do you know? The trailer casts it as typical Hollywoodish "I've created a monster" mismash... but optimistically, we can hope the screenwriter puts in a surprise twist ending, revealing that all along the "rampaging" robots were working for the good of humanity.
There's a number of obvious plotlines that'd allow that to happen.
The Robots themselves came up with a zeroeth law:
That's not another law, but a simple consequence of law #1. Any robot with sufficient inferential ability would deduce that on its own.
2. EXPANDED LEVEL SIZE. This is one of those biggies. Doom, for all its technological prowess of the time,
That's not a technical limitation at all. It's an artistic limitation, if anything.
Doom could've been designed so that you never visited a room twice. That'd have placed a lot more work onto the level designers, and for what? It's actually more fun & realistic to let the player come into a threat situation with some knowledge of the terrain occasionally, rather than making every one of them an unknown.
Of course, the extent to which recent console games (Halo) reused maps was wrong.
wouldn't have a problem hiring an ex-Navy
Not "having a problem" with something is a long way from seeing it as a positive, though.