1. Never burn bridges. 2. Never quit without allowing your employer to suggest a remedy. 3. You can only threaten to quit once, because your employer knows that you are more likely to quit at a later date. 4. Fight the organization, not the people in the organization. 5. Be selfish. When you do good, expect something in return -- compensation, experience, a favor to be repaid later (maybe), networking opportunities, etc. 6. Realize that every job has its drawbacks, and your goal is to weigh those drawbacks and find your own personal "happy medium".
1) Rendering to texture is an API issue. DirectX has pretty decent support for this, the only performance hit being a state change when you switch to this mode. OpenGL's support with pbuffers exists on most cards, but less spiffy until this Uberbuffer thing gets standardized (wait awhile, that is). The memory question, well, that's a valid point if you like to stack windows 10 deep, but clever management of buffers will help this.
2) Huh? Simple alpha-blending is essentially a no-op on modern cards, unless we're talking Doom-3 style mega-layering. I don't think that's the context here.
There are some mathematical algorithms that could still operate on a slightly-nondeterministic machine. The Miller-Rabin test is an algorithm to determine whether or not a given number is prime, by trying to find "witness" numbers to its compositness. (http://en.wikipedia.org/wiki/Miller-Rabin_test) The more numbers you search w/o finding a witness, the more likely you are to have a prime number. By choosing a high enough number of iterations, you can prove that the probability that the number is prime is higher than the probability that the machine had a hardware fault -- that is, true for all practical purposes.
It seems that if there was a CPU that returned wrong answers occasionally, you'd simply have to run more iterations of this algorithm to make it have the same confidence level. I can think of other areas like optimization and search where nondeterminism would not be totally unwelcome, and might be even beneficial.
I understand your point, but I believe that there is potential for many more exploits in Java than you let on. For instance, here's the.so file for the AWT shared libraries on my 1.4.2 JDK:
3059052 Jun 4 2004/usr/local/java/jre/lib/i386/libawt.so
That's 3MB (w/o debug info) of potentially exploitable wrapper code, lots of which depends on complex and (and potentially exploitable) Win32/X/Motif/whatever code. The rest of the shared libs total to about 6MB. Java's native layer is not thin like say, Smalltalk -- part of the reason for this is performance, part is feature set.
Also, a quick search for "buffer overflow" on the Java bug database brings up 1860 results. I'm sure one or two of those involve native code and were/are potentially exploitable, just no one got around to it.
Yes, I'm sure much of the Java codebase is heavily audited, and the common things like socket/file I/O are pretty secure. But I wouldn't say "all is well" if I had to bet my business on that being true.
Just to be pedantic... Cyc as a project has been around at lot longer than Cycorp the company... since at last 1986, according to this Google/Deja Groups post.
Maybe if you're really *cool* you already have low entropy, that is, you just stand around and look cool. Maybe you don't *need* to be told you're cool, because like the MC Heisencool effect, you might no longer be cool after you're told you're cool.
For true... the thing had tons of built-in models, a HUGE seamless outdoor location (remarkable for the '286 era), and a nifty editing system with multiple cameras. Oh, and flight simulation with about 15 planes:) Customization was a pain, and character animation was non-existent, but I think the limitations bred more creative filmmaking. I still run it in Dosbox.
There's also the unlikely situation of a craft that could generate enough lift via the atmosphere to pull its perigee out of the center of the Earth. I think these would have to be some very large wings however:)
Now, using a rubber band would be impractical -- when you apply an impulse to an idealized orbit, the trajectory will change but it will always return to the same point at which you applied the impulse. Therefore your Gremlin would crash into the Earth's surface. You would need a second rubber band floating in space to actually reach orbit.
Now, this is *unless* you take advantage of perturbations of a second body -- like the Moon -- to alter your trajectory enough to bring the perigee up to 400 km. This is what I am assuming you meant.
Sincerely, Pedant McGee
Unscripted is the best comedy
on
Humor in Games?
·
· Score: 3, Insightful
The author of the article probably has not experienced "emergent comedy" in a game. Take the Sims, for instance as a recent example -- it's funny when your party guests get stuck in a corner, fall asleep and urinate all over themselves. No, but being a writer for Slate, the author probably has only gone to real parties of this type.
What do you bet a producer somewhere is reading this and saying "A-ha! If unscripted comedy is funny... Let's make a reality show game!!" Which would then, of course, be designed with a linear storyline:)
What I've noticed about Macs is that even though there are less games total, there are a greater ratio of GOOD titles to sucky, buggy, amateurish games. Having less of a selection might not sound like an advantage to most people, but it is to casual gamers and impulse buyers.
Also because the Mac hardware platform allows fewer permutations than a PC, when I spend my tiny gaming budget on a product, I'll have a greater assurance it'll work. I gave up PC gaming because I was sick of fiddling with drivers, patches, and so forth.
I'll give you that Mac gaming is not for the hardcore. But it's good for the three-games-a-year-because-i-have-a-job-or-a-kid-o r-a-girlfriend crowd.
The only reason the ISS crew spend their time doing housekeeping is to give them something to do and thus justify their budget. A ship in hibernation would only have to drift, make very minor course corrections (maybe), supply oxygen and scrub CO2 (at a much lower rate than during normal human activity), supply heat, etc. We have enough experience in manned and unmanned spacecraft and designing redundant systems to do this.
IMHO Google is getting smacked around for taking the geek stance instead of the smart-for-business stance. Everyone in business knows that perception is reality. By not excluding the cache directories by *default*, Google risked the perception that they created an insecure product. Good for you, Google, for not compromising your design and adding this unsavory hack, but the elegance of a technical solution has nothing to do with good business.
I don't see why you'd need to actually simulate 100k entities -- you would want to use some sort of level-of-detail calculation to simplify the stuff that is not of immediate concern to the goals of the simulation. For instance, why simulate traffic in Reston, VA when the focus is on an incident in downtown DC?
Rather, the simulation should simulate the macro-scale flow of traffic in these areas and only simulate down to the individual car when a player is near those areas. Of course, maybe it's easier (and better grant $$) to just throw a buncha supah-hardware at the problem.
Meh. Sorry, I use MythTV but not for music. The MythMusic module is better than it was but still not good enough to use on a daily basis, and definitely not scalable to 1,000's of music files. Right now my music solution is "mpg123 -z -@ playlist.m3u"
I like the concept of pair programming, but it seems in practice it's hard for everyone to get behind it, and there are other things you can do that are just as good. Like, you can get everyone in the same room with their computers close together. You can occasionally ask "what are you doing now?" and solicit opinions on your own tasks. You can give show-and-tell sessions every day. You can help write unit tests for someone else's code. If everyone understands the high-level issues, and the priorities, and helps each other occasionally, that's what matters.
I had a similar idea a few months back, when I realized I was spending 10+ hours per week sitting in my car or on the Metro. I just wish I had more choices than NPR, RIAA, or AM radio. I like the idea of XM radio, but it doesn't work underground and doesn't have the variety that the web can provide. I'd rather listen to kooky bloggers commenting on micro-issues than another 10-minute summary of what Big Media thinks important. It'd also be a great way to get exposed to new independent artists.
If there was a system that had a 2-hour program assembled from various feeds personalized to my taste (maybe even a printout to read along, and view pictures) then I'd be on board. My weekly magazines only last a couple days on the subway.
I have an affection for my MythTV, being that it's in such a cute little Shuttle mini-case, but there are drawbacks:
* Code is still version 0.16. Sometimes my SO calls me @ work asking nicely how I un-freeze the screen. * The best encoding solution is the PVR-250 card. But some newer cards have firmware which causes small glitches that aren't entirely diagnosible. * To support both interlaced video and overscan (filling the entire display) you need to pick your video chipset/driver very very carefully. Deep perusal of FAQs and threads is neccessary. * The XML program data is *not* forever free. It is a service provided on a temporary basis by zap2it.com, and who knows when their goodwill will expire. * Hate to say it, but the other modules besides TV are not so great. I find myself just using xmms and mplayer. * If you spend the week or so required to get one running, you will have friends that will ask you to build them one. You will have to politely ask that they just save themselves the trouble and buy a TiVo:)
Best features: Commercial detection, multiple encoders, great web interface, no Big Brother in your living room:)
Isn't the TrueType hinting still encumbered by patent until 2008 or so, and thus disabled by default in most Linux distros? I can see this being a sore point for all Linux office apps. (yeah there are Type I fonts, but everyone has their favorite TTFs they cart around)
It's called the free market. Any project that desparately needs superior software will somehow find superior engineers to build said software. You don't often find a gaggle of JavaScript programmers running around building missile guidance systems, do you?
Professionals get degrees because humans require their services, humans that need that assurance. Companies hire software engineers, they should be able to tell in an interview whether or not they're clueful (or subscribe to the interviewer's particular coding religion, which is another matter).
And about that Software Engineering Body of Knowledge... I'd like to add a node to that: If you're serious about a project, get some bandwidth for its web page.
For those who feel like they're downloading the page over a 110-baud modem with an acoustic coupler located in the same room as a Disaster Area concert, here are some othersimilarcomparisons.
Crap... I guess I'd better start writing programs, then, because I can't tell if they are going to end or not!:>
Point well taken, but you can still have alot more safety in conventional languages without encountering the Halting problem. I foresee languages in the future being linked to automatic theorem provers, and even having humans assist in doing the tricky bits of the proofs.
Really, doing a formal proof of your program is the ultimate CYA.:)
Slashdot Mirror
1. Never burn bridges.
2. Never quit without allowing your employer to suggest a remedy.
3. You can only threaten to quit once, because your employer knows that you are more likely to quit at a later date.
4. Fight the organization, not the people in the organization.
5. Be selfish. When you do good, expect something in return -- compensation, experience, a favor to be repaid later (maybe), networking opportunities, etc.
6. Realize that every job has its drawbacks, and your goal is to weigh those drawbacks and find your own personal "happy medium".
Yeah, well on my Debian box I find myself doing this alot:
$ apt-cache search svgalib
$ sudo apt-get install xmame-svga
$ time xmame-svga
real 1d3h22m1.043s
Yeaaah, I'm just not sure about that right now...
1) Rendering to texture is an API issue. DirectX has pretty decent support for this, the only performance hit being a state change when you switch to this mode. OpenGL's support with pbuffers exists on most cards, but less spiffy until this Uberbuffer thing gets standardized (wait awhile, that is). The memory question, well, that's a valid point if you like to stack windows 10 deep, but clever management of buffers will help this.
2) Huh? Simple alpha-blending is essentially a no-op on modern cards, unless we're talking Doom-3 style mega-layering. I don't think that's the context here.
There are some mathematical algorithms that could still operate on a slightly-nondeterministic machine. The Miller-Rabin test is an algorithm to determine whether or not a given number is prime, by trying to find "witness" numbers to its compositness. (http://en.wikipedia.org/wiki/Miller-Rabin_test) The more numbers you search w/o finding a witness, the more likely you are to have a prime number. By choosing a high enough number of iterations, you can prove that the probability that the number is prime is higher than the probability that the machine had a hardware fault -- that is, true for all practical purposes.
It seems that if there was a CPU that returned wrong answers occasionally, you'd simply have to run more iterations of this algorithm to make it have the same confidence level. I can think of other areas like optimization and search where nondeterminism would not be totally unwelcome, and might be even beneficial.
I understand your point, but I believe that there is potential for many more exploits in Java than you let on. For instance, here's the .so file for the AWT shared libraries on my 1.4.2 JDK:
/usr/local/java/jre/lib/i386/libawt.so
3059052 Jun 4 2004
That's 3MB (w/o debug info) of potentially exploitable wrapper code, lots of which depends on complex and (and potentially exploitable) Win32/X/Motif/whatever code. The rest of the shared libs total to about 6MB. Java's native layer is not thin like say, Smalltalk -- part of the reason for this is performance, part is feature set.
Also, a quick search for "buffer overflow" on the Java bug database brings up 1860 results. I'm sure one or two of those involve native code and were/are potentially exploitable, just no one got around to it.
Yes, I'm sure much of the Java codebase is heavily audited, and the common things like socket/file I/O are pretty secure. But I wouldn't say "all is well" if I had to bet my business on that being true.
Just to be pedantic ... Cyc as a project has been around at lot longer than Cycorp the company ... since at last 1986, according to this Google/Deja Groups post.
Maybe if you're really *cool* you already have low entropy, that is, you just stand around and look cool. Maybe you don't *need* to be told you're cool, because like the MC Heisencool effect, you might no longer be cool after you're told you're cool.
Word.
I did #5 in my dorm. I would say about 110 VAC.
Mofo -- Gish has versions for OS X and Linux. Indie game and console game are mutually exclusive BTW. Too much coin/tribute.
For true... the thing had tons of built-in models, a HUGE seamless outdoor location (remarkable for the '286 era), and a nifty editing system with multiple cameras. Oh, and flight simulation with about 15 planes :) Customization was a pain, and character animation was non-existent, but I think the limitations bred more creative filmmaking. I still run it in Dosbox.
There's also the unlikely situation of a craft that could generate enough lift via the atmosphere to pull its perigee out of the center of the Earth. I think these would have to be some very large wings however :)
Now, using a rubber band would be impractical -- when you apply an impulse to an idealized orbit, the trajectory will change but it will always return to the same point at which you applied the impulse. Therefore your Gremlin would crash into the Earth's surface. You would need a second rubber band floating in space to actually reach orbit.
Now, this is *unless* you take advantage of perturbations of a second body -- like the Moon -- to alter your trajectory enough to bring the perigee up to 400 km. This is what I am assuming you meant.
Sincerely,
Pedant McGee
The author of the article probably has not experienced "emergent comedy" in a game. Take the Sims, for instance as a recent example -- it's funny when your party guests get stuck in a corner, fall asleep and urinate all over themselves. No, but being a writer for Slate, the author probably has only gone to real parties of this type.
... Let's make a reality show game!!" Which would then, of course, be designed with a linear storyline :)
What do you bet a producer somewhere is reading this and saying "A-ha! If unscripted comedy is funny
What I've noticed about Macs is that even though there are less games total, there are a greater ratio of GOOD titles to sucky, buggy, amateurish games. Having less of a selection might not sound like an advantage to most people, but it is to casual gamers and impulse buyers.
o r-a-girlfriend crowd.
Also because the Mac hardware platform allows fewer permutations than a PC, when I spend my tiny gaming budget on a product, I'll have a greater assurance it'll work. I gave up PC gaming because I was sick of fiddling with drivers, patches, and so forth.
I'll give you that Mac gaming is not for the hardcore. But it's good for the three-games-a-year-because-i-have-a-job-or-a-kid-
The only reason the ISS crew spend their time doing housekeeping is to give them something to do and thus justify their budget. A ship in hibernation would only have to drift, make very minor course corrections (maybe), supply oxygen and scrub CO2 (at a much lower rate than during normal human activity), supply heat, etc. We have enough experience in manned and unmanned spacecraft and designing redundant systems to do this.
IMHO Google is getting smacked around for taking the geek stance instead of the smart-for-business stance. Everyone in business knows that perception is reality. By not excluding the cache directories by *default*, Google risked the perception that they created an insecure product. Good for you, Google, for not compromising your design and adding this unsavory hack, but the elegance of a technical solution has nothing to do with good business.
I don't see why you'd need to actually simulate 100k entities -- you would want to use some sort of level-of-detail calculation to simplify the stuff that is not of immediate concern to the goals of the simulation. For instance, why simulate traffic in Reston, VA when the focus is on an incident in downtown DC?
Rather, the simulation should simulate the macro-scale flow of traffic in these areas and only simulate down to the individual car when a player is near those areas. Of course, maybe it's easier (and better grant $$) to just throw a buncha supah-hardware at the problem.
Meh. Sorry, I use MythTV but not for music. The MythMusic module is better than it was but still not good enough to use on a daily basis, and definitely not scalable to 1,000's of music files. Right now my music solution is "mpg123 -z -@ playlist.m3u"
I like the concept of pair programming, but it seems in practice it's hard for everyone to get behind it, and there are other things you can do that are just as good. Like, you can get everyone in the same room with their computers close together. You can occasionally ask "what are you doing now?" and solicit opinions on your own tasks. You can give show-and-tell sessions every day. You can help write unit tests for someone else's code. If everyone understands the high-level issues, and the priorities, and helps each other occasionally, that's what matters.
I had a similar idea a few months back, when I realized I was spending 10+ hours per week sitting in my car or on the Metro. I just wish I had more choices than NPR, RIAA, or AM radio. I like the idea of XM radio, but it doesn't work underground and doesn't have the variety that the web can provide. I'd rather listen to kooky bloggers commenting on micro-issues than another 10-minute summary of what Big Media thinks important. It'd also be a great way to get exposed to new independent artists.
If there was a system that had a 2-hour program assembled from various feeds personalized to my taste (maybe even a printout to read along, and view pictures) then I'd be on board. My weekly magazines only last a couple days on the subway.
I have an affection for my MythTV, being that it's in such a cute little Shuttle mini-case, but there are drawbacks:
:)
:)
* Code is still version 0.16. Sometimes my SO calls me @ work asking nicely how I un-freeze the screen.
* The best encoding solution is the PVR-250 card. But some newer cards have firmware which causes small glitches that aren't entirely diagnosible.
* To support both interlaced video and overscan (filling the entire display) you need to pick your video chipset/driver very very carefully. Deep perusal of FAQs and threads is neccessary.
* The XML program data is *not* forever free. It is a service provided on a temporary basis by zap2it.com, and who knows when their goodwill will expire.
* Hate to say it, but the other modules besides TV are not so great. I find myself just using xmms and mplayer.
* If you spend the week or so required to get one running, you will have friends that will ask you to build them one. You will have to politely ask that they just save themselves the trouble and buy a TiVo
Best features: Commercial detection, multiple encoders, great web interface, no Big Brother in your living room
Isn't the TrueType hinting still encumbered by patent until 2008 or so, and thus disabled by default in most Linux distros? I can see this being a sore point for all Linux office apps. (yeah there are Type I fonts, but everyone has their favorite TTFs they cart around)
It's called the free market. Any project that desparately needs superior software will somehow find superior engineers to build said software. You don't often find a gaggle of JavaScript programmers running around building missile guidance systems, do you?
... I'd like to add a node to that: If you're serious about a project, get some bandwidth for its web page.
Professionals get degrees because humans require their services, humans that need that assurance. Companies hire software engineers, they should be able to tell in an interview whether or not they're clueful (or subscribe to the interviewer's particular coding religion, which is another matter).
And about that Software Engineering Body of Knowledge
For those who feel like they're downloading the page over a 110-baud modem with an acoustic coupler located in the same room as a Disaster Area concert, here are some other similar comparisons.
Crap... I guess I'd better start writing programs, then, because I can't tell if they are going to end or not! :>
:)
Point well taken, but you can still have alot more safety in conventional languages without encountering the Halting problem. I foresee languages in the future being linked to automatic theorem provers, and even having humans assist in doing the tricky bits of the proofs.
Really, doing a formal proof of your program is the ultimate CYA.