This is what happens when the legal system fails to prevent what many people think should be a crime; in this case spam. Because there has been no satisfaction through legal channels, people resort to "vigilante justice". Much more serious examples can be seen in Mexico were people have lost trust in the judicial system.
While this is on dangerous ground, there are some important differences between other kinds of vigilanteism: most of the harassment is as legal as the spam itself; spamming regulation, unlike "speaking harshly about the government", is being held up less by constitutional free-speech issues than by the lobbying influence of so-called "legitimate spammers" who don't want to be blocked along with the "septic tank" crew.
However, we all must be very careful about "borderline" civil rights cases, especially in today's anti-rights climate (at least in the US). Just as anti-terrorist laws can be then applied to other groups, it's easy to imagine cases where anti-spamming measures could be also be abused.
Neural nets and "traditional Algorithms" aren't magic bullets, and each subtask you mention "id cars (and their relative speeds)", "find speed limit signs" is a hard problem. While neural nets do have uses in limited cases, they never lived up to all the hype. There's a very big difference between toy problem-domains like "blockworld" or "wumpus world" and the real world, and a lot of very plausible-sounding methods just don't scale to reality.
People have been working on "smart cars" for decades, thowing every technique you mention (and quite a few more) at the problem, and I don't think we're close to having a robot car that could be trusted to drive unsupervised in real traffic...
However, feel free to prove me wrong by winning the contest!
I think the trend of the gaming market shifting away from PCs to consoles could be a great thing for linux and other operating systems. My P3-733 (Win98) has become "obsolete" enough that I stopped buying games or downloading demos; I later got a Powerbook with a Rage128 video card; so even among the small number of Mac games, it will still suck on anything recent.
But once I "let go" of expecting to run games on it and decided only to buy console games, it became a great computer for surfing, audio, etc. I started booting my PC with Knoppix on the rare occasion that I turn it on (it had been less than stable in Windows, and I really have gotten too old to enjoy reinstalling everything from scratch just to have a few months of "clean machine").
Now I can't deny that for certain genres of games, the consoles can't really offer a comparable alternative, and a lot of things suck about the "closed market" of consoles. However, it's really nice to have games work out of the box, run at the correct frame-rate, not crash or require updating drivers, not have weird sound problems, etc. To be honest, if you take games out of the equation, most people can be very satisfied with both a less powerful machine *and* a relatively small suite of application software. Linux still lacks good video solutions, and (IMHO) a competitive GUI. But these are solvable problems; wheras getting every new game to be ported to linux or run well under emulation is not realistic.
Win95 and later can also run 32-bit DOS programs (built for DOS4GW and friends), which was a really nice environement for full-screen games--use more than 640K without crapping around, 32-bit registers, etc, but still have complete control of the machine. Mmm... VGA, mode-X, writing your own joystick routines; those were the days...
This is not a.sig--it's just something I typed at the end of my message.
It could copy MP3s from iTunes over the broadband adapter or firewire(?) to optional PS2 hard-disk, and also stream internet radio over the BBA... I know there's a PS2 app out there that streams media from a computer, but it'd be cooler if I didn't have to have my computer on to listen to MP3s or internet radio through my AV system...
The Xbox definitely has all the hardware bits to make an awesome media box (ethernet adapter, reasonable sound output, big hard disk, available remote control), but Microsoft seems much more restrictive than Sony in letting developers access the ports... (on PS2 you can pretty much write any USB device driver you like, but on Xbox you can't talk to anything but Xboxes or Microsoft servers via the ethernet...)
for a platform that is clinging to a small piece of the software market. If you write code for Windows, linux, sgi, palm, Playstation2, GameCube, Xbox, etc, etc, you get a C (or sometimes C++) interface. Bear in mind I haven't really used objective C since messing around with NeXT's interface builder in college in the nineties, and for all I know it is really good for GUI programming in some way...
I have to agree that when screwing around with writing OS-X apps for my powerbook, it seemed like there were a zillion different Apple APIs that didn't seem especially well organized or well-documented. However, porting a full-screen 3D game to SDL/OpenGL was pretty easy (although sad to say, even when testing it on an 800Mhz iMac w/ a GeForce, the performance is not that impressive, probably mainly due to memory bandwidth issues. (The GameCube is pretty zippy with a 486 MHz PPC attached to 24 MB of very speedy RAM by comparison...)[ed: do you have a point?]
However, I still love using my Powerbook, because it works well, looks cool, and it's nice using an OS that looked like had some real graphic designers involved. It's also nice to have a UNIX box with a "real" GUI, although it would have been nice if mach/darwin was a little less "different". A CPU/memory bus that could compete with Intel would be nice, too.
I think one of the best features of OS-X is that applications are just self-contained.app directories, not the multiarmed monstrosities that put a zillion files in Windows/System, do who knows what to the registry, replace some shared dll used by some other app, etc, etc. My Win2K machine at work is rock solid, because I only run 4NT, epsilon, command-line compilers, and Outlook Express. All the artists, however, who do things like run photoshop or install scanners get no end of trouble on identical machines. (Not that I haven't had issues with my powerbook--basically all computers suck, I guess.)
Hmm, this is pretty rambling. Final score:
Windows: 3 chili peppers
Mac: 29.3 bootie points
linux: B+
OS/2: thank you for playing...
I read some article in Car & Driver or some such about measuring fuel consumption on various cars with fuels of different octane ratings... they claimed that most modern cars use their knock sensor to run their timing & mixture just on the edge of knocking, and so if you put in higher octane, some cars could achieve slightly higher fuel economy (and presumably power output).
However, this contradicts what I've been told about aftermarket chips--such that running the Jim Conforti chip in my E30 removes the "safety barrier" that previously existed for running at lower than recommended (91) octane. Maybe this is just a feature of late nineties and newer cars.
For kicks I downloaded the binary image of the chip and ran it through a disassembler for my ECU's microprocessor. It's a zillion lines of code with branches and stuff all over the place--even if I knew enough about engines to know what kinds of adjustments to make, just reverse-engineering the program would be a pretty big task. I'd almost want to write some sort of ECU-MAME for testing....
At our company we never use a debugger, and we tend to have very few bugs in the codebase at any time and have never missed a milestone yet. (knock on wood). One great thing about using printf as a debugging tool is that the fact that it _is_ inconvenient leads you to actually look at the code and think, instead of just stepping through the function to "find the bug"...when you look at the code in a questioning manner, you often find other bugs that aren't currently manifesting themselves.
We never have any problems with memory leaks or such, because we always wrap all OS interaction with our own subsystem that can do validation, we overload the "new" operator to take an extra name parameter, so that in debug mode every allocation is named so we can dump out any unfreed blocks on shutdown, etc, etc. Basically if you design each subsystem to be "bulletproof" (defensive programming--never trust the "user" of any API not to misuse it, even if you're making it for yourself!), and riddled with asserts, than bugs show up as an assertion failure or panic 90 percent of the time, usually right after the bug has occurred, and a bus error only 10 percent of the time. (Oh, and I guess the one cheat is that we have our own exception handler that traps these and does a stack trace, especially handy when you get an assertion in some very low-level function that's called in a zillion places. Then you can turn the crash address into an offset into the function, and look at the assembly, which is another good thing to do periodically to see how "honest" the compiler is...).
I know that we are very nonstandard in our practices, and that it probably comes down to personal preference, but I never wish for a debugger... usually the stuff that's really hard to track down involves understanding really complex state information, or doing things in real time, that a few watch variables would still be confusing--often it's faster to code up some sort of custom telemetry display into the program that shows the information in a way that's more understandable (such as a graph versus time or or a symbolic dump of a DMA chain)--make the computer work for you, instead of trying to do everything in your head. The "off by one" or pointer errors are usually much simpler to track down than the "conceptual" errors, which really need a thinking cap and the scientific method, not fancy tools. Also, not using a debugger makes it much easier to port to different platforms, because we're not heartbroken if our favorite GUI debugger isn't available for platform X. --
This isn't a.sig--it's just something I typed on the last line.
(jumping in here)
I think having a Direct-X emulation layer won't make that much of a big difference, because there's a pretty big fixed cost of supporting a new platform (QA, testing, support, compatibility, marketing, manufacturing, etc) that will dominate any "one week of development" (of course you should always multiply any time estimate by at least two). As a developer, it would be "fun" to run on Macs, but it's really up to the publisher, and whether or not they feel chasing that 7% is worth it (since even just developing for the PC versus consoles is starting to be a small market, Mac/linux are even farther down the line!)
If you're already a multiplatform title, or if your title has a decent abstraction layer, putting in a decent OpenGL/OS-X kernel shouldn't take much more than a few weeks anyways. I know nothing about how sound works on OS-X, but it seems to be "in flux". A while ago I tried porting my company's code to run on my powerbook in my spare time, and I got pretty far in only a few evenings despite the fact that I know nothing about Macs (able to view shaded 3d models using the game's engine, still need texturing and sound, need some endian-conversions)--the main problem is not having the control key by the "A" for emacs--is there a good OS-X equivalent of caps2ctrl? I would bet if I tried again now, now that we've done GameCube (big-endian CPU, OpenGL-like API), it would be even easier. But then again, going from a hobby project to a shippable project is a pretty big task (compatibility testing, installers, all the usual bullshit). For example, when I upgraded from 10.1 to 10.1.5, it broke my code (aglChoosePixel Format stopped accepting AGL_FULLSCREEN as an argument for some reason). I suppose making an OS-X downloadable "experimental/as-is" executable that uses the data from the PC retail box is one middle ground.
...an occurrence known as oblateness, which can be thought of as the difference between a football and a soccer ball; the football has a larger radius at the equator.
What kind of example is this? Besides the US/European differences on what a football is, what is the "radius of a football at the equator"? If the equator is defined by the plane parallel to the stitching, than this forms a pointy ovoid with a non-constant radius. Perhaps "soccer ball" and "inflated whoopie cushion" would have been better examples...
Anyways, think of how much more real estate we'll have in the tropics if we continue to expand the equator. Let's all drive hummers!
How the heck did they make a mobile phonograph skip-proof? Perhaps they had a spring-loaded arm that mashed the needle down into the record, or some sort of shock-mounting...
Anyways, from the photo it looks like you could probably feed it records while driving; perhaps with a box of records on the floor where we now have "center consoles".
>Now. How about a way of lacing shoes where you only have one crossing of the lace between each pair of holes, but you can still tie in a bow, like 99% of human shoe users do?
So who are these non-human shoe users, and what do they do with their laces? Or do they have to use a different lacing algorithm because they have three columns of holes instead of two like us humans?
I'll make the example more explicit in case I was not clear--the language is C or C++:
void foo()
{
char baz[1024];
}
Here any normal compiler must allocate one kilobyte off the stack for baz. If the array was declared static, then it would be allocated out of the static data section. While one could conceive of a compiler making an implicit call to malloc or something to allocate it from the heap, that would be really nonstandard and break a lot of games like ours that don't even use the standard c runtime memory manager. The only choice the compiler has with automatic variables is whether to put them on the stack or just keep them in a register, and few machines have 1K registers.
As to the other comment, allocating from the stack is likely to be faster than even a very efficient heap, but for memory efficiency you often need to have as small of a stack as possible, but this gets very system specific.
Anyways, my main point was not that allocating the array from the stack was bad but that the person didn't understand how local variables were implemented by the compiler.
We had to do watermarking when we were passing out press copies of our game disk to keep them from appearing on the internet the next day. Luckily executable code, unlike audio, has a lot of places to hide watermarking bits, so we were able to pull a "diff-proof" solution out of our asses. Of course we only needed to make fifty copies or so, which is a very easy problem domain.
It'd be interesting, though, to check out the literature and see how the "real" solutions compare to the cheesy method we employed.
It really depends on what you're listening for. I am able to recognize a lot of compression artifacts, poorly mic'd vocals, I can even (I think!) hear the "extra treble" on vinyl played through a high quality phonograph. However, most of my favorite recordings have only mediocre recording quality. It really depends on whether you're listening to the music or judging it's representation.
Okay, someone start the tubes vs. solid-state battle already!
I use things I learned in the math and physics classes I took in college far more than anything I learned in my CS classes. If you just get a CS degree without doing a lot of programming on your own, you're unlikely to become a great game programmer, IMHO.
Ideally learn how to code in high school or earlier, use college for stuff like Linear Algebra, Calculus, and maybe a little CS theory to "round yourself out", and to understand how compilers work! Take some art classes or something. None of this pansy-ass "write a 4-function calculator" term-project stuff. I would suspect any really good game programmer would still do it in his/her spare time if it didn't pay!
(warning: extended rant by crusty game programmer to follow)
While it's true that most CS concepts are language independent, I am very alarmed to see Java now being used at my alma mater. While it does have OOP features and is probably useful for future web programmers, the lack of pointers and explicit memory management widens the gap in understanding from source code to assembly, and makes the computer a "magic black box".
I am amazed at how little recent CS grads seem to know about what's really going on in the machine. For example, caught one declaring a huge local array variable in a function, asked him why he was putting all that memory on the stack, got a blank look in response.
Maybe that's okay if you're going to be writing web front ends, but I'd hate to have this person writing VU microcode for a PS2 game!
In my dream world, someone with a CS degree should at least have a rough idea of how a language like C++ gets compiled into assembly, what linking is, and how the CPU actually executes those instructions.
Software engineering has become a hugely diverse field--in some branches, your skill is finding existing libraries and modules and stitching them together to get things done quickly and efficiently, whereas in game programming the first thing you do is throw out all those standard libraries and write your own to save 17K. (Of course, I really don't have a clue what really goes on in mainstream programming, but I'm suspect somehow that it doesn't involve hand-optimizing inner loops or counting I-cache misses...)
A computer science program should prepare someone for any of these fields, so it has to steer clear of really application-specific stuff and give a solid grounding both in theory and in problem-solving skills, taking a scientific approach to debugging, etc, etc. I just hate to have them think that anything is magic--the proper attitude is to have the ability at least in theory to write your own version of any tool or library you use, and not be afraid or ignorant.
Slashdot Mirror
While this is on dangerous ground, there are some important differences between other kinds of vigilanteism: most of the harassment is as legal as the spam itself; spamming regulation, unlike "speaking harshly about the government", is being held up less by constitutional free-speech issues than by the lobbying influence of so-called "legitimate spammers" who don't want to be blocked along with the "septic tank" crew.
However, we all must be very careful about "borderline" civil rights cases, especially in today's anti-rights climate (at least in the US). Just as anti-terrorist laws can be then applied to other groups, it's easy to imagine cases where anti-spamming measures could be also be abused.
People have been working on "smart cars" for decades, thowing every technique you mention (and quite a few more) at the problem, and I don't think we're close to having a robot car that could be trusted to drive unsupervised in real traffic...
However, feel free to prove me wrong by winning the contest!
But once I "let go" of expecting to run games on it and decided only to buy console games, it became a great computer for surfing, audio, etc. I started booting my PC with Knoppix on the rare occasion that I turn it on (it had been less than stable in Windows, and I really have gotten too old to enjoy reinstalling everything from scratch just to have a few months of "clean machine").
Now I can't deny that for certain genres of games, the consoles can't really offer a comparable alternative, and a lot of things suck about the "closed market" of consoles. However, it's really nice to have games work out of the box, run at the correct frame-rate, not crash or require updating drivers, not have weird sound problems, etc. To be honest, if you take games out of the equation, most people can be very satisfied with both a less powerful machine *and* a relatively small suite of application software. Linux still lacks good video solutions, and (IMHO) a competitive GUI. But these are solvable problems; wheras getting every new game to be ported to linux or run well under emulation is not realistic.
(this space for rent)
This is not a .sig--it's just something I typed at the end of my message.
The Xbox definitely has all the hardware bits to make an awesome media box (ethernet adapter, reasonable sound output, big hard disk, available remote control), but Microsoft seems much more restrictive than Sony in letting developers access the ports... (on PS2 you can pretty much write any USB device driver you like, but on Xbox you can't talk to anything but Xboxes or Microsoft servers via the ethernet...)
I have to agree that when screwing around with writing OS-X apps for my powerbook, it seemed like there were a zillion different Apple APIs that didn't seem especially well organized or well-documented. However, porting a full-screen 3D game to SDL/OpenGL was pretty easy (although sad to say, even when testing it on an 800Mhz iMac w/ a GeForce, the performance is not that impressive, probably mainly due to memory bandwidth issues. (The GameCube is pretty zippy with a 486 MHz PPC attached to 24 MB of very speedy RAM by comparison...)[ed: do you have a point?]
However, I still love using my Powerbook, because it works well, looks cool, and it's nice using an OS that looked like had some real graphic designers involved. It's also nice to have a UNIX box with a "real" GUI, although it would have been nice if mach/darwin was a little less "different". A CPU/memory bus that could compete with Intel would be nice, too.
I think one of the best features of OS-X is that applications are just self-contained .app directories, not the multiarmed monstrosities that put a zillion files in Windows/System, do who knows what to the registry, replace some shared dll used by some other app, etc, etc. My Win2K machine at work is rock solid, because I only run 4NT, epsilon, command-line compilers, and Outlook Express. All the artists, however, who do things like run photoshop or install scanners get no end of trouble on identical machines. (Not that I haven't had issues with my powerbook--basically all computers suck, I guess.)
Hmm, this is pretty rambling. Final score:
Windows: 3 chili peppers
Mac: 29.3 bootie points
linux: B+
OS/2: thank you for playing...
However, this contradicts what I've been told about aftermarket chips--such that running the Jim Conforti chip in my E30 removes the "safety barrier" that previously existed for running at lower than recommended (91) octane. Maybe this is just a feature of late nineties and newer cars.
For kicks I downloaded the binary image of the chip and ran it through a disassembler for my ECU's microprocessor. It's a zillion lines of code with branches and stuff all over the place--even if I knew enough about engines to know what kinds of adjustments to make, just reverse-engineering the program would be a pretty big task. I'd almost want to write some sort of ECU-MAME for testing....
We never have any problems with memory leaks or such, because we always wrap all OS interaction with our own subsystem that can do validation, we overload the "new" operator to take an extra name parameter, so that in debug mode every allocation is named so we can dump out any unfreed blocks on shutdown, etc, etc. Basically if you design each subsystem to be "bulletproof" (defensive programming--never trust the "user" of any API not to misuse it, even if you're making it for yourself!), and riddled with asserts, than bugs show up as an assertion failure or panic 90 percent of the time, usually right after the bug has occurred, and a bus error only 10 percent of the time. (Oh, and I guess the one cheat is that we have our own exception handler that traps these and does a stack trace, especially handy when you get an assertion in some very low-level function that's called in a zillion places. Then you can turn the crash address into an offset into the function, and look at the assembly, which is another good thing to do periodically to see how "honest" the compiler is...).
I know that we are very nonstandard in our practices, and that it probably comes down to personal preference, but I never wish for a debugger... usually the stuff that's really hard to track down involves understanding really complex state information, or doing things in real time, that a few watch variables would still be confusing--often it's faster to code up some sort of custom telemetry display into the program that shows the information in a way that's more understandable (such as a graph versus time or or a symbolic dump of a DMA chain)--make the computer work for you, instead of trying to do everything in your head. The "off by one" or pointer errors are usually much simpler to track down than the "conceptual" errors, which really need a thinking cap and the scientific method, not fancy tools. Also, not using a debugger makes it much easier to port to different platforms, because we're not heartbroken if our favorite GUI debugger isn't available for platform X. .sig--it's just something I typed on the last line.
--
This isn't a
If you're already a multiplatform title, or if your title has a decent abstraction layer, putting in a decent OpenGL/OS-X kernel shouldn't take much more than a few weeks anyways. I know nothing about how sound works on OS-X, but it seems to be "in flux". A while ago I tried porting my company's code to run on my powerbook in my spare time, and I got pretty far in only a few evenings despite the fact that I know nothing about Macs (able to view shaded 3d models using the game's engine, still need texturing and sound, need some endian-conversions)--the main problem is not having the control key by the "A" for emacs--is there a good OS-X equivalent of caps2ctrl? I would bet if I tried again now, now that we've done GameCube (big-endian CPU, OpenGL-like API), it would be even easier. But then again, going from a hobby project to a shippable project is a pretty big task (compatibility testing, installers, all the usual bullshit). For example, when I upgraded from 10.1 to 10.1.5, it broke my code (aglChoosePixel Format stopped accepting AGL_FULLSCREEN as an argument for some reason). I suppose making an OS-X downloadable "experimental/as-is" executable that uses the data from the PC retail box is one middle ground.
Anyways, think of how much more real estate we'll have in the tropics if we continue to expand the equator. Let's all drive hummers!
Anyways, from the photo it looks like you could probably feed it records while driving; perhaps with a box of records on the floor where we now have "center consoles".
void foo()
{
char baz[1024];
}
Here any normal compiler must allocate one kilobyte off the stack for baz. If the array was declared static, then it would be allocated out of the static data section. While one could conceive of a compiler making an implicit call to malloc or something to allocate it from the heap, that would be really nonstandard and break a lot of games like ours that don't even use the standard c runtime memory manager. The only choice the compiler has with automatic variables is whether to put them on the stack or just keep them in a register, and few machines have 1K registers.
As to the other comment, allocating from the stack is likely to be faster than even a very efficient heap, but for memory efficiency you often need to have as small of a stack as possible, but this gets very system specific. Anyways, my main point was not that allocating the array from the stack was bad but that the person didn't understand how local variables were implemented by the compiler.
It'd be interesting, though, to check out the literature and see how the "real" solutions compare to the cheesy method we employed.
Okay, someone start the tubes vs. solid-state battle already!
Ideally learn how to code in high school or earlier, use college for stuff like Linear Algebra, Calculus, and maybe a little CS theory to "round yourself out", and to understand how compilers work! Take some art classes or something. None of this pansy-ass "write a 4-function calculator" term-project stuff. I would suspect any really good game programmer would still do it in his/her spare time if it didn't pay!
While it's true that most CS concepts are language independent, I am very alarmed to see Java now being used at my alma mater. While it does have OOP features and is probably useful for future web programmers, the lack of pointers and explicit memory management widens the gap in understanding from source code to assembly, and makes the computer a "magic black box".
I am amazed at how little recent CS grads seem to know about what's really going on in the machine. For example, caught one declaring a huge local array variable in a function, asked him why he was putting all that memory on the stack, got a blank look in response. Maybe that's okay if you're going to be writing web front ends, but I'd hate to have this person writing VU microcode for a PS2 game!
In my dream world, someone with a CS degree should at least have a rough idea of how a language like C++ gets compiled into assembly, what linking is, and how the CPU actually executes those instructions. Software engineering has become a hugely diverse field--in some branches, your skill is finding existing libraries and modules and stitching them together to get things done quickly and efficiently, whereas in game programming the first thing you do is throw out all those standard libraries and write your own to save 17K. (Of course, I really don't have a clue what really goes on in mainstream programming, but I'm suspect somehow that it doesn't involve hand-optimizing inner loops or counting I-cache misses...)
A computer science program should prepare someone for any of these fields, so it has to steer clear of really application-specific stuff and give a solid grounding both in theory and in problem-solving skills, taking a scientific approach to debugging, etc, etc. I just hate to have them think that anything is magic--the proper attitude is to have the ability at least in theory to write your own version of any tool or library you use, and not be afraid or ignorant.
No black boxes, please!