...my experience walking around the Googleplex, where most people have those 24" Dell LCDs that you can rotate 90 degrees, is that the Unix developers seem to rotate them to be vertical (more rows of code on the screen, less columns), and the Windows developers kept them horizontal (more columns, less rows).
It wasn't a scientific study or anything. But if I had to guess, I'd guess that's what decades of using vi and years of using Visual Studio does to your preferences for code layout.
(I don't know what various filesystems actually do, this is just how I would assume it's done, at least on systems designed for case-insensitivity...ext2 or FFS probably would suffer from the issues you mention about scanning the whole directory.)
On a case-insensitive filesystem, your done if you're lucky. If not lucky, you need to do a linear scan of the whole damn directory. And yet Windows and Mac OS have had case-insensitive filesystems for years and somehow they are usable, even with Unicode filenames.
You can't restore the original case of a string afterwards, but you can always make it lowercase. This is called "case folding." You can fold two strings to a lowercase form, and then compare them for equality or whatnot. Works with Unicode, too.
Then there is the issue of internationalization. For example, consider "I" and "i". Some places have an uppercase with the dot, and other places have a lowercase without the dot. The rules for uppercasing and lowercasing differ from what most people are used to. Oh crap! This issue doesn't exist on a case-sensitive filesystem. While folding Unicode chars is frequently presented as an unsolvable problem ("what do you do with the letter with the squiggly thing above it? Or converting that German capital 'B' thing to two lowercase 's' chars? There are MILLIONS OF THESE!")... there are actually very few cases in the grand scheme of things. Most languages don't have upper and lower case, after all.
Here's the whole list of characters that need to "folded" to a lowercase form, accounting for instances where it will cause the string to grow (like that German 'B' thing):
(And you can hash those chars too, so folding a string doesn't involve hundreds of conditionals.)
If you don't care about Unicode, case folding an English ASCII char is 2 lines of C code, and a few more if you want extended ASCII.
Once you have a filename, you can store it in the filesystem as the specifically-entered characters, so you don't lose the original casing, but also store with it a hash of the case-folded version. Now whenever you need to look up a specific filename, you case-fold it, hash that folded string, and look it up that way against the hash you previous calculated when creating the file. Now it's as fast as the case-sensitive filesystem, minus the overhead of folding a small string.
Because of the way directory listings are done (read then look up stats) you can generally square the above numbers. Ouch. The way directory listings are done doesn't change...readdir() is the same in all cases, and your lookup is still a hash. If you had to scan, the first run is slow anyhow due to disk bandwidth and seek speeds, but then a modern OS can cache the inodes to speed this up for the next run.
App needs to make a file. App sees that file does not seem to exist. App writes file. Complex international case rules mean that no, the file DOES exist, and it gets clobbered. I would think that stat(filename) would not report the file doesn't exist if open() would then clobber it, at least not for case-sensitivity issues.
If your app decides about a file's existence by using readdir() until it finds it, and doesn't properly case-fold, and didn't call open() with O_EXCL, then not only did you go the long way about it, you got what you deserved for clobbering the file.
Actually, if you don't just open(O_CREAT | O_EXCL) to check for existence and create if missing in one step, then you'll have an atomicity problem anyhow. Use the services the OS provides, they are there for a reason.
Tom Leonard, a programmer from Valve, gave a fascinating talk about this at GDC this year, about retrofitting multicore support into Half-Life 2 (specifically, into the Source Engine, which powers Half-Life 2). Not surprisingly, this talk was named "Dragged Kicking and Screaming"...
There was a lot of really good wisdom in there, whether you are writing a game or something else that needs to get every possible performance boost.
I'm sure they probably drew from 20+ years worth of whitepapers (and some newer ones about "lock-free" mutexes, see chapter 1.1 of "Game Programming Gems 6"), but what I walked away from the talk with was the question: "why the hell didn't _i_ think of that?"
There were several techniques they used that, once you built a framework to support it, made parallelizing tasks dirt simple. A lot of it involves putting specific jobs onto queues and letting worker threads pick them up when they are idle, and being able to assign specific jobs to specific cores to protect your investment in CPU cache.
Most of the rest of the work is building things that don't need a result immediately, and trying to build things that can be processed without having to compete for various pieces of state...sometimes easier said than done, sure. But after hearing his talk, I was of the opinion that while parallelism is always more complex than single-threaded code, doing this well is something most developers aren't even _thinking_ about yet. In most cases, we're not even at the point where we can talk about _languages_ and _tools_, since we aren't even using the ones we have well.
I have a dedicated server hosted by GoDaddy, and a few days before Christmas got an automated DMCA takedown request for something allegedly on the server.
I got an email from GoDaddy saying "please take this down and respond that, under penalty of perjury, you did so."
I happened to be checking my email at this moment, 12:30 at night, so I looked into the issue and responded to the email that the issue was resolved.
The next morning, my server wasn't responding to pings. So I email again saying, "hey, I took care of the complaint before you unplugged my machine, can you, you know, plug it back in?"
Day goes by. Eventually I get a response:
"Thank you for your response to the Copyright Department. In order to reactivate the site in question we will need you to provide the following information in a single email response:
A. An electronic signature. (This can be a scanned copy of your physical signature, or as simple as typing your full name.)
B. Identification of the material in question.
C. A statement, under penalty of perjury, that the material has either been removed or will promptly be removed."
So I write back again, explaining the details. Again.
Day goes by. I call the tech support number and explain the situation. The tech support guy (who was very nice) told me he couldn't help, and I should try emailing the address I already had, twice. Sigh. I do it again.
Day goes by. I get the following response:
"Thank you for contacting the Copyright Claims Department. Unfortunately your previous email did not include a statment under penalty of perjury. Please submit a complete content removal statement at your earliest convenience to have your services reactivated. For your reference an example of a complete copyright removal statement is listed below.
I, John Doe, under penalty of perjury, will remove the offending content at http://www.mydomainname.com/myfile/page.htm promptly after the reactivation of my services./John Doe/ John Doe (Please accept the above as an electronic signature.)"
Okay, great. I finally found the magic formula. I copy the template exactly and fill in my details, send it out.
Day goes by. I get this back:
"Thank you for your email. We appreciate your responsiveness and cooperation on this matter. We have re-activated the account and services associated with your site. As some services require some time for propagation to take full effect, please allow 1-2 hours for the changes to take effect."
Ok, progress, finally.
Day goes by. Day goes by.
Server still isn't responding. I email tech support to see if there's a problem. They tell me to try using the automatic reboot request form on the web panel. Sure enough, the system responds within minutes.
So basically, they were really on top of that from every angle. In the week my server was unavailable, I arranged for hosting at one of their competitors, Dreamhost.com, who rocks quite a bit. Specifically because of this incident, I probably won't renew the GoDaddy contract when it expires, but I also wonder if I'm really safer at any other ISP in America.
It's partially a shame because I really was perfectly satisfied with GoDaddy's hosting before this incident, and they just flat out botched it. The server provides bandwidth offloading for my main site, so I could survive without it for a week, but I couldn't imagine someone trusting their business to GoDaddy if they can callously cut your oxygen for a week.
It's also a shame because the DMCA required GoDaddy to have a knee-jerk reaction in the first place. I was basically accused, tried, and convicted by my service provider without any evidence or chance to defend myself. They should be looking at this as bad for business in even well-handled situations, and recognize that the best thing to do is take
No it's not. It generally maps to buttons 4 and 5, specified in your X server config file, and causes problems for hardware with more than 5 buttons. XInput is rarely used by most apps (and most X servers), and there're lots of programs out there now that would fail if you mapped the mousewheel to different buttons, since it's a de facto standard to have them on buttons 4 and 5.
Drives me nuts when people say fundamentally incorrect things with authority, since they always get modded "Insightful."
Yes, because blizzard WANTS TO support all the distributions out there. I bet if there was only one Linux there would be WoW for it. It's not FUD to say that Linux is fractured among two main desktop environments, two major X11 implementations, and more distros than I can count. Mac OS X is supported because there is only one.
Oh, stop saying this. It didn't stop me from shipping Unreal Tournament 2004 without a single line of code that is Gnome, KDE, Red Hat, Ubuntu, Gentoo, or Suse (or whatever) specific. I figured (at least, I hoped) if there WERE issues in a given desktop or distro, the distro would make changes to support a popular game, but in practice, this never needed to happen. We used SDL (which is really the Gold Standard on Linux now, like DirectX would be on Windows), and OpenAL, which hid all sorts of other platform differences under the hood. Loki_setup handled installation across all distros for us, and we didn't worry about package managers.
UT2004 was probably my most popular endeavor, but there are lots of other games I've shipped with similar experiences.
People don't support Linux for a number of reasons, and while one of them is almost certainly the belief that Linux is terribly "fractured," in reality, it's not even remotely a problem...at least not in terms of shipping a game.
If 47 senators are so for it, maybe they should just "opt-in" to giving up their rights, instead of passing another odious law that will apply to them too? Oh yeah, that's because it won't apply to them. They are elite. Their names will never be on a no-fly list.
...has been working great for me, for several commercial games like Unreal Tournament 2004. Over the past five years, I've shipped several products using it, both on commercial CDs and downloadable installers.
It _is_ a little quirky in some regards, but once you get it working, it pretty much works everywhere.
If you use it, please use our codefork at http://icculus.org/loki_setup/, since the Loki Games version died with Loki, and we've put several man months of further development into it since (largely improving things as we ship new software with previously unexpected requirements, a MacOS X port, more archive formats and other enhancements). We're pretty fast to respond when someone has a bug, too.
Otherwise, I'd say give people a tarball and let them sort it out.:) Yes, trying to make distro-specific packages is SO BAD as to make this a better option...even between the various RPM-based distros.
Someone DID mention that it's nice to enable those distros to repackage it in their preferred format, if there's a want, and I think that's an interesting idea as long as you don't rely on people to show up and do it. Gentoo, for instance, provides their own packages for most of the games I've shipped, which will even extract the data off the retail CDs if need be, etc...this empowers Gentoo users to have a consistent experience, but they can still use my loki_setup based installer if they want, as can those without a "real" distro package. This seems to be the least-messy solution at the moment, and it allows the distro maintainers to compete on features while you maintain a single, decent and universal solution yourself.
At least, this works well for me. Your mileage may vary.
Hi, I was the one that ported Unreal Tournament 2004 to the Mac...among other games. I'm probably qualified to speak to this.
There's an urban legend that Apple has a zero-tolerance policy for games. If you're an Apple employee writing a video game in your spare time, that's grounds for dismissal. Rumor is that this is not enforced, but still in the employee manual (or stone tablets outside 1 Infinite Loop or something).
This is probably not true, but it says a lot about the culture at Apple. Games are not in the business plan. At all. Since the Apple II was so wickedly ahead of everyone else in terms of game capabilities, a lot of people saw it as a "game system" or...well, a toy. Funny how that sort of thing blows up in your face, huh? So there's a historical bias against it at the upper levels. It's a flinch reaction. Several layers of upper management are going to have to retire or die (or both) before this attitude changes.
That being said, this article is pitching a silly (and unoriginal) idea. It's hard enough trying to evangelise the Mac to game publishers, but it gets even harder when Big Publisher starts asking the very legitimate question: "How come Apple put time, money, and manpower into porting Half-Life 2 and wants me to shoulder the port for my own title?"
A fair question, to be sure. Other results would be less concern at the original gamehouse for portability (we'll let Apple fix that) and the choking off of the few companies that are actually doing this today. Oh, and we haven't even gotten to the "could this even be profitable for Apple" question yet.
That being said, here're a few things Apple CAN be doing:
1) Get more developer relation people that do nothing but deal with games. These are the people game developers call when they need something done...OS bugs that need someone to fight for developer priority, hardware access, questions about marketing your product and general connecting of the right people. They also go to game developers/publishers to pitch the Mac and encourage them to see a profitable business model in Apple's platform. Apple used to have two of these people working this job. They now have one. I would bet that they'll have zero before 2005 is over. I suspect that the position is the red-haired stepchild of the company. I respect Rich for every day he gets up and continues to choose to go to work.
2) Backport OpenGL fixes. Apple's GL team is top-rate, but once they are working on a new release, you are out of luck. This is company policy, not the GL team's fault. Let me illustrate this for you. Right now you might be desperately trying to get a game running for Christmas, ported from a DirectX9-based game, and lo and behold, you find that a Pixel Shader you moved over to GL_ARB_vertex_program triggers a kernel panic in OSX. You get the team to look at it promptly, thanks to that one devrel soldier who's still standing, and it gets fixed, but the fix is rolled into Tiger.
Well, Tiger's not shipping for 6+ months, and you ain't shipping this Christmas. And when you do ship, you'll be telling a bunch of people that you need to buy a 150$ upgrade to the OS to play. This is more acceptable for Big Name Games, since somehow people will swallow this, albeit unhappily, when it's UT2004 or World of Warcraft. Will they swallow it for an indie game that's a 15 dollar, online-only purchase?
I'll be fair and say that, as far as I can tell, the overwhelming majority of Mac users upgrade to the latest OS anyhow, because generally the MacOS upgrades have been significantly compelling. When I screw up a Linux build in the year 2004 and a game stops running on a Red Hat 6.0 install from 1999, I get angry email. When ut2003 required people to upgrade to Jaguar, I never got a single bug report or complaint. Figure that one out. Still, if there is no upgrade path at all, you're timetable gets screwed. Put that shit in Software Update, Apple!
3) Give out free hardware, and give it out gratuitously. The Games Department (t
I have to throw in on this topic, since I've been doing this for several years now.
First, contracting is roughly akin to prostitution. You might think you're escaping some sort of pimp/whore relationship by not working for A Big Company, but you really are doing the same thing, just for multiple bosses. To be perfectly honest, you're trading a safety net for the possibility of more income.
That safety net is damned important, though. A lot of people don't have the stomach to function without it. There's nothing wrong with that, though.
Things like "health benefits" and "401k plans" and stuff go right out the window. You better get some health insurance out of your own pocket. (Listen to me...You Better Get Some Health Insurance!)
The people turning the Cogs of American Capitalism as 9-to-5 coders aren't as dumb as you suggest. Many of them are brilliant and talented, and they are focusing on building interesting things. Someone else is worried about finding revenue for them to do so.
And blahblahblah, money isn't everything.
So here's what I think: it's not the idea of a "normal job" that offends you. It's the idea of a boring job you can't stand. You don't want to maintain someone's else's shitty code, you don't want to write some buzzword crap pie that is neither spectacular nor innovative. I suspect that making someone else money is really secondary...it's a sour grapes response for being relegated to mediocrity.
Yeah, I can dig that.
So for you, based on the paragraph of you that I know, I would say: find an interesting job. I know, easier said than done, especially in this market. But there's bound to be something out there. Take some interviews (take them regardless of what else you do), and find the company that is building something interesting, and failing interesting, find the company that is building something beautiful. There's a lot of edification in elegance.
Ok, so about contracting.
Here's my advice. Find a vertical market.
My first paying jobs were writing Java code when no one did that. Later, when I was out of college and looking for work so I could be a Normal Person, I landed a job doing Linux and Mac development, because no one did that, but I did it for fun in my spare time, so I was naturally qualified for a job that couldn't be filled. If you're spending time on any open source project of any weight, chances are you are in a similar position. I just had the luxury of poverty...Linux was my primary OS out of need, but it paid off when command lines and C code and kernel builds were second nature to me. If you take these things for granted, that's good for you, and something you should try to convey in job interviews and contract pitches. Employers want smart people that can pick up new things above all else, right?
So I went to work for a company in Orange County doing Linux video games (you might have heard of them). When they went out of business, I moved in with my parents (turning in my membership card in the Normal Person Society), and started doing Linux and Mac game development, on my own, for companies that needed it. You know what? Nobody else did that. Now everyone needs a Mac port or a Linux dedicated server...people call me and ask if I'm available. I've been jokingly introduced at trade shows as "The Linux Game Industry". Vertical market, baby.
I don't live with my parents anymore, but I never got my membership in the Normal Person Society renewed. I guess that's a happy ending.
There are _always_ markets where people will pay top dollar for talented individuals. In the 90s, it was Java, and Linux, and embedded stuff, etc, but you can pull out any number of good examples for any era.
The world is filled with unemployed Visual Basic coders that took a college course on it because they heard there was money in it. It is _trivial_ to stand out from the herd. This is NOT measured in how many programming languages you know, but by what you can do, what you can pick up o
Converting a number between floating point and integer on Macs is actually quite expensive compared to x86 systems. Converting between double and float has a severe penalty, too.
Also, Macs tend to suffer a worse penalty for CPU cache misses.
Then again, there's a handful of general purpose registers on an x86, and 64 of them on the PPC (96 if you count the Altivec registers), so it's assumed that x86 systems will optimize for these cases more than the PPC, whereas the PPC assumes you'll load what you need into registers, work on it, and go back to RAM only when absolutely forced to. This means you should define a bunch of local variables, and load as much as possible into them at the start of a function. On the PPC, this can be several orders of magnitude faster, whereas on the x86, it might be a little slower (since those locals won't translate into registers, you end up shuffling between the heap and stack and working out of RAM anyhow).
Pre-G5, there's no square root instruction on the CPU. You can fake it with the fsqrtre opcode (which all Macs have, but I believe is optional in the PPC spec, too), but this gives you extremely low precision (five bits...you can actually GUESS with more precision!), but it's fast (and frequently "good enough" after two rounds of newton-raphson)...we used this (with Newton-Raphson) in UT2003/UT2004 without any noticable rendering artifacts. The G5 has a real, full-precision square root instruction, which spanks the cheap reciprocal method to boot, but will crash your program (SIGILL) on a G4 or lower. If you just call the system's C library's sqrt(), it'll do the right thing based on the running CPU, but to give you real precision, it won't using the reciprocal opcode...so on a G5, sqrt() gives good performance, on a G4, it'll eat up tons of CPU. The flyby intro on the original Unreal Tournament was spending about 17-20% of it's CPU time in sqrt() until I swapped in the reciprocal version.
While I'm talking about sqrt(), a lot of other things developers take for granted on their x86 floating point unit, like sin(), aren't implemented in hardware on the PPC.
Division on the PPC causes a complete pipeline stall (use multiplication where possible). GCC doesn't appear to optimize this case behind the scenes at this point.
On the G5, instructions are broken up into "dispatch groups"...usually five instructions, I think, but it varies due to a few factors. If you write to a memory address and read it back in the same dispatch group, it causes a pipeline stall. This is called an "LSU reject". Developer documentation says that in these cases you should either move the store and load to seperate dispatch groups, or at least pad out the dispatch group with no-ops so the load will be in a different group. GCC doesn't doesn't necessarily optimize this for you at this point, but I'm not sure where Apple's GCC branch lies in relation to the mainline version (which can now handle this).
LSU rejects are, however, a somewhat common optimization gotcha:// An untested example:
static int myvar1;// force out of register.
myvar1 = somefunc();// store.
int myvar2 = myvar1 + 10;// read.
The solution is to move the addition down a few lines of code so that the compiler doesn't put it in the same dispatch group...padding out with no-ops isn't really practical, and it's something the compiler should be doing anyhow. More to the point, your x86 developer isn't going to think something as harmless as having those two lines next to each other would be an optimization issue. Why should he?
Optimizations "truths" of the x86 aren't necessarily true on the PowerPC, either:
1) Loop unrolling is generally believed to be a "good optimization" on the x86, but it thrashes your instruction cache on the PPC. Actually, this is probably true on modern x86 chips nowadays, too, but on the PPC, Cache Is King.
Mesa is not anywhere near "reasonably fast" without hardware support. Software Mesa renders a frame every few seconds. Pixomatic can get 70 to 100 fps in many scenes. Then again, Mesa is meant to be a correct OpenGL implementation, whereas Pixomatic is concerned with speed over quality (and isn't an OpenGL API at all).
Beyond some minor convenience functions, the major thing we took from ROTT was the sound code...which, ironically, I wrote for Duke3D.
Matt Saettler's EDUKE project was looking into moving to Windows using the icculus.org Build port, but the stumbling block was the lack of sound code (since the Apogee Sound System was a direct-to-hardware sort of thing).
So they sent me a header file and I reimplemented the audio library months ago. It was a pleasant surprise when ROTT was released that we finally had a testbed for that code (and a chance to clean out some bugs). This is also why ROTT was so functional so fast on Linux.
I think it's funny (and flattering) that there's a race between several win32 developers to get a WinDuke running...all but one of them is using the icculus.org port of the Build Engine to do it, and they STILL haven't kept pace with our Linux port....although hats off to Jonathon Fowler, who did his own port of everything from scratch for Windows: http://jonof.edgenetwork.org/buildport/
I have to say this, because someone recommended assembly language with a straight face.
Some things you should remember:
1) Programming languages are just an expression of a problem's solution. The less time you can spend learning to express, the more time you can be solving.
2) Teaching someone logic is really the goal at early stages. Teaching them how a computer works (i.e. - low level programming) is really just noise at the start. Teaching someone object orientation is problematic in the opposite direction.
3) Your mileage may vary by age. A ten year old learns VERY differently than an 11 year old.
4) You're probably a genious that learned to program by plowing through manuals and books and scouring the web. This makes you the exception to the rule. Most people do NOT learn this way.
5) Not everyone will be good at programming, ever, but everyone can make it further than Hello World...they can make it to the point where they are conscious that they are _creating_ something.
6) Most people benefit from immediate visual feedback. Teaching someone how to compile and link slows them down. Teaching someone to write to stdout slows them down. Slapping together something in Visual Basic and then showing them how to hook up responses gets them moving quickly, especially when they can hit F5 and see what happens immediately. VB adds other complexity, though, which makes something like LOGO better in terms of simplicity.
7) Not everyone wants to be a coding god. Some people just want to see what programming is, some people _think_ they are l33t hax0rs but don't know shit (you always get these in large classes), some people are there against their will (parents made them do it, etc)...just keep it simple and fun. Most people won't take this to be the start of a career in software development.
I used to teach programming courses for summer camps. Java is just totally inaccessible as a first language. I tried. Visual Basic actually worked very well. Object orientation is best explained by NOT explaining it (people will naturally understand what a "push button" is, but it's a waste of time to explain how it's "subclassed" from a "widget". These things can come later). Half the trick is not scaring them off in the first few weeks.
If there was a free Logo package that didn't suck, I'd have used that (maybe there is, I couldn't find one at the time, but that was years ago).
My response to it all was to develop Toby (http://icculus.org/toby/), which is a variation on Logo.
I'm the developer that did the 64-bit port of UT2003 (and the Linux port, and the Mac port...).
You need to keep two things in mind:
1) The OpenGL renderer is not as fast as the Direct3D renderer at this time. This is not the Athlon64's fault. You can see this on 32-bit Windows, since it can use both renderers. Since this is a Linux port of the game, we're using the GL renderer on the Athlon64 at this time.
2) The "stat fps" command isn't really a good benchmarking method.
3) This is a prerelease version of the game running on a prerelease version of SuSE running on prerelease drivers running on prerelease hardware. Please don't consider this "benchmark" to be representative!
I port video games to Linux for a living, so I am probably qualified to comment on this.
Do NOT optimize for Wine. You probably can't anyhow, since both Win32 (at least, DirectX) and Winelib are moving targets to varying degrees, what works and works well in one version of Wine will not necessarily do so in another.
I think Wine is an excellent piece of work, but I'd imagine even the Wine developers would rather have native Linux applications than emulated win32 apps (and if they don't, they should).
This is doubly true for game development, where you need every CPU cycle you can reasonably get.
Wine, Winelib, and WineX are really meant to be bridges to make Linux more feasible in the short term by letting Win32 programs run in some form, even if they just limp along. They are afterthought solutions to running software that we have no real ability to use, but think we can't do without.
The ideal solution is to write portable code in the first place. Be mindful of what you write, and follow some basic principles:
1) Don't tie yourself to a compiler. If you build on Visual C, take time to build on a different compiler (specifically, GCC) every now and then. Getting code to compile on various platforms is half the battle.
2) Don't tie yourself to a platform's API. Use cross-platform libraries and toolkits where you can, use abstraction layers in your own code where you can't. If you do this right, a good chunk of the porting work is just filling in stubs for a new platform. For game development, you should be looking at Simple Directmedia Layer for most of your needs. Other libraries like my own PhysicsFS can abstract file handling for you. OpenAL can give you 3D positional audio if SDL's stereo output is insufficient, and OpenGL gives you 3D accelerated graphics if SDL's 2D linear framebuffer is insufficient.
3) If PowerPC (MacOS, specifically) is of interest to you, be conscious of byte ordering. Always be conscious of structure packing regardless of platform. If 64-bit platforms (Alpha, Itanium, Hammer) are of interest to you in the future, don't do silly things like cast pointers to ints and such.
4) Don't use assembly code. Ever. If you _must_ use it, you better have a C fallback. Be smart and use NASM on win32 and Linux, so you don't have to deal with the massive differences in inline syntax between Visual Studio and GCC.
If you are more than one developer, the easiest way to do this is to have a devcrew made up of at least one person for each targeted platform. This makes it easy to make sure that things aren't silently breaking on MacOS while you write code for Win32, since that developer will catch it in his next code sync (you _are_ using source revision tools, right?).
The only thing I can find that is a (happy) Utopian novel is B.F. Skinner's Walden II, which is honestly a very interesting read. The book interested largely in the mechanics and psychology required for such a society, with just enough plot to keep Skinner's ideas moving.
I have been told that it was the basis for Brave New World in some form or another, but it might just be Skinner's ideas that Huxley was borrowing from/parodying.
I suppose you could count the original Walden (which has no relation to Walden II beyond the idea of utopia), but living alone doesn't qualify as Utopia...after all, the reasons that Utopias fall apart are...other people.
Sartre was right, after all.
Also, the concept of "Utopia" is usually written about for the sense of irony...reference 1984...plus we can find lots of stories like Animal Farm: good intentions turned to mud by human flaws. The point of Utopia, from a writers view, is to trample on it, generally. Take that for what it's worth.
This just bit me in the ass, so I'm passing it on.
The privilege separation code in OpenSSH 3.3 does not work with 2.2 Linux kernels.
It relies on mmap() semantics that aren't supported before kernel 2.4 (maybe 2.3.x). OpenSSH will configure, compile, and install successfully. It will start up, but it will NOT accept connections.
Your clients will get a "broken pipe" message, your syslog will get an "mmap: invalid parameter" message.
The solutions are:
Upgrade to kernel 2.4 or higher.
Don't compile in Privilege Separation.
You might be able to compile privsep in and disable it, but I couldn't get this to work. Maybe I had a typo in my config file. I dunno.
I didn't see this anywhere until I dug into my syslog and then the OpenSSH mailing list. You have been warned.
If you do have kernel 2.4, you should read README.privsep in the openssh source distro, since you need to create a special directory and user/group for this (which also bit me in the butt...even if sshd had worked on 2.2, when I restarted it remotely, it didn't come back up because it didn't have that user...yeah, yeah, rtfm.:) )
It's probably worth saying that just about any story falls into a few of Joseph Campbell's archetypes. Some fit more, some fit less, but no story I'm aware of fits them all. Indeed, some of the archetypes are contradictory.
The notion that Luke Skywalker is a Campbellian hero apparently wasn't talked about until years after A New Hope was made. Still, that doesn't mean there aren't Campbellian elements...Anakin fits this, too. After he becomes Vader and his son overthrows him, it's likely that episodes 7, 8, and 9 would detail Luke's fall to the Dark Side, and another Jedi rising up to defeat him. It's cyclical, but that's part of the myth.
Some of these elements overlap with Spider-Man. Then again, maybe it's just a coming-of-age story with web-slingers. I dunno.
Here's my brief dissertation on the literary value of Spider-Man...hopefully I'll get less flames than Jon Katz.:)
Support Righteous Babe Records, Ani Difranco's indie label. They have a lot of high quality, frequently politically charged, and non-mainstream music. On top of that, the music doesn't suck.
None of that money goes to a big corporation; most of it goes back into making music and fighting the good fight, so to speak. If you want to put your money where your mouth is, go support Ani and the artists she publishes.
If you just want free music, you should get involved with etree.org, which is a community that distributes "bootlegs" of live concerts...the bootlegs are legal, recorded from performances of taper-friendly bands, such as Phish, older Grateful Dead shows, Bela Fleck...stuff like that. The bands that allow this tend to fit a certain profile (lots of improvising, etc), so if you don't like songs that can be fed to you in 3.5 minutes between commercials, you aren't going to like this avenue, however, there is a genuine community being fostered here that tends to be more artistic and intellectual, and frequently, very tight-knit for a bunch of virtual strangers. It's kind of cool, actually, and unlike the P2P mentality of leeching everything you can, there's a sense of the value of contributing back.
etree.org also happens to be Linux-friendly; there are links for XMMS plugins on the frontpage, etc.
The ultimate problem of these massive media corporations is they _do_ have a product that you want. I mean, if you want N'Sync (or that Episode 2 DVD, or some new Disney-owned Anime, etc...), then you can only get it in one place. I can also respect that not everyone is going to be falling over themselves for the latest release from indie band Bitch and Animal, but you _can_ consider this a chance to broaden your horizons; entertainment doesn't have to be mindless, and can in fact be a bettering activity.
Slashdot Mirror
--ryan.
That's Bungie (the Halo company), not Valve (the Half-Life company).
--ryan.
...my experience walking around the Googleplex, where most people have those 24" Dell LCDs that you can rotate 90 degrees, is that the Unix developers seem to rotate them to be vertical (more rows of code on the screen, less columns), and the Windows developers kept them horizontal (more columns, less rows).
It wasn't a scientific study or anything. But if I had to guess, I'd guess that's what decades of using vi and years of using Visual Studio does to your preferences for code layout.
I'm an 80-character man, myself.
--ryan.
You can't restore the original case of a string afterwards, but you can always make it lowercase. This is called "case folding." You can fold two strings to a lowercase form, and then compare them for equality or whatnot. Works with Unicode, too. Then there is the issue of internationalization. For example, consider "I" and "i". Some places have an uppercase with the dot, and other places have a lowercase without the dot. The rules for uppercasing and lowercasing differ from what most people are used to. Oh crap! This issue doesn't exist on a case-sensitive filesystem. While folding Unicode chars is frequently presented as an unsolvable problem ("what do you do with the letter with the squiggly thing above it? Or converting that German capital 'B' thing to two lowercase 's' chars? There are MILLIONS OF THESE!")
Here's the whole list of characters that need to "folded" to a lowercase form, accounting for instances where it will cause the string to grow (like that German 'B' thing):
http://www.unicode.org/Public/3.2-Update/CaseFold
(And you can hash those chars too, so folding a string doesn't involve hundreds of conditionals.)
If you don't care about Unicode, case folding an English ASCII char is 2 lines of C code, and a few more if you want extended ASCII.
Once you have a filename, you can store it in the filesystem as the specifically-entered characters, so you don't lose the original casing, but also store with it a hash of the case-folded version. Now whenever you need to look up a specific filename, you case-fold it, hash that folded string, and look it up that way against the hash you previous calculated when creating the file. Now it's as fast as the case-sensitive filesystem, minus the overhead of folding a small string. Because of the way directory listings are done (read then look up stats) you can generally square the above numbers. Ouch. The way directory listings are done doesn't change...readdir() is the same in all cases, and your lookup is still a hash. If you had to scan, the first run is slow anyhow due to disk bandwidth and seek speeds, but then a modern OS can cache the inodes to speed this up for the next run. App needs to make a file. App sees that file does not seem to exist. App writes file. Complex international case rules mean that no, the file DOES exist, and it gets clobbered. I would think that stat(filename) would not report the file doesn't exist if open() would then clobber it, at least not for case-sensitivity issues.
If your app decides about a file's existence by using readdir() until it finds it, and doesn't properly case-fold, and didn't call open() with O_EXCL, then not only did you go the long way about it, you got what you deserved for clobbering the file.
Actually, if you don't just open(O_CREAT | O_EXCL) to check for existence and create if missing in one step, then you'll have an atomicity problem anyhow. Use the services the OS provides, they are there for a reason.
--ryan.
Tom Leonard, a programmer from Valve, gave a fascinating talk about this at GDC this year, about retrofitting multicore support into Half-Life 2 (specifically, into the Source Engine, which powers Half-Life 2). Not surprisingly, this talk was named "Dragged Kicking and Screaming" ...
There was a lot of really good wisdom in there, whether you are writing a game or something else that needs to get every possible performance boost.
I'm sure they probably drew from 20+ years worth of whitepapers (and some newer ones about "lock-free" mutexes, see chapter 1.1 of "Game Programming Gems 6"), but what I walked away from the talk with was the question: "why the hell didn't _i_ think of that?"
There were several techniques they used that, once you built a framework to support it, made parallelizing tasks dirt simple. A lot of it involves putting specific jobs onto queues and letting worker threads pick them up when they are idle, and being able to assign specific jobs to specific cores to protect your investment in CPU cache.
Most of the rest of the work is building things that don't need a result immediately, and trying to build things that can be processed without having to compete for various pieces of state...sometimes easier said than done, sure. But after hearing his talk, I was of the opinion that while parallelism is always more complex than single-threaded code, doing this well is something most developers aren't even _thinking_ about yet. In most cases, we're not even at the point where we can talk about _languages_ and _tools_, since we aren't even using the ones we have well.
--ryan.
I have a dedicated server hosted by GoDaddy, and a few days before Christmas got an automated DMCA takedown request for something allegedly on the server.
/John Doe/
I got an email from GoDaddy saying "please take this down and respond that, under penalty of perjury, you did so."
I happened to be checking my email at this moment, 12:30 at night, so I looked into the issue and responded to the email that the issue was resolved.
The next morning, my server wasn't responding to pings. So I email again saying, "hey, I took care of the complaint before you unplugged my machine, can you, you know, plug it back in?"
Day goes by. Eventually I get a response:
"Thank you for your response to the Copyright Department. In order to reactivate the site in question we will need you to provide the following information in a single email response:
A. An electronic signature. (This can be a scanned copy of your physical signature, or as simple as typing your full name.)
B. Identification of the material in question.
C. A statement, under penalty of perjury, that the material has either been removed or will promptly be removed."
So I write back again, explaining the details. Again.
Day goes by. I call the tech support number and explain the situation. The tech support guy (who was very nice) told me he couldn't help, and I should try emailing the address I already had, twice. Sigh. I do it again.
Day goes by. I get the following response:
"Thank you for contacting the Copyright Claims Department. Unfortunately your previous email did not include a statment under penalty of perjury. Please submit a complete content removal statement at your earliest convenience to have your services reactivated. For your reference an example of a complete copyright removal statement is listed below.
I, John Doe, under penalty of perjury, will remove the offending content at http://www.mydomainname.com/myfile/page.htm promptly after the reactivation of my services.
John Doe
(Please accept the above as an electronic signature.)"
Okay, great. I finally found the magic formula. I copy the template exactly and fill in my details, send it out.
Day goes by. I get this back:
"Thank you for your email. We appreciate your responsiveness and cooperation on this matter. We have re-activated the account and services associated with your site. As some services require some time for propagation to take full effect, please allow 1-2 hours for the changes to take effect."
Ok, progress, finally.
Day goes by.
Day goes by.
Server still isn't responding. I email tech support to see if there's a problem. They tell me to try using the automatic reboot request form on the web panel. Sure enough, the system responds within minutes.
So basically, they were really on top of that from every angle. In the week my server was unavailable, I arranged for hosting at one of their competitors, Dreamhost.com, who rocks quite a bit. Specifically because of this incident, I probably won't renew the GoDaddy contract when it expires, but I also wonder if I'm really safer at any other ISP in America.
It's partially a shame because I really was perfectly satisfied with GoDaddy's hosting before this incident, and they just flat out botched it. The server provides bandwidth offloading for my main site, so I could survive without it for a week, but I couldn't imagine someone trusting their business to GoDaddy if they can callously cut your oxygen for a week.
It's also a shame because the DMCA required GoDaddy to have a knee-jerk reaction in the first place. I was basically accused, tried, and convicted by my service provider without any evidence or chance to defend myself. They should be looking at this as bad for business in even well-handled situations, and recognize that the best thing to do is take
UT2004 for Linux sold _way_ more than 1000 units. So did the Mac OS X version.
The UT2004 Linux/Mac/Win64 guy,
--ryan.
http://developer.apple.com/tools/sharkoptimize.htm l
'nuff said.
--ryan.
No it's not. It generally maps to buttons 4 and 5, specified in your X server config file, and causes problems for hardware with more than 5 buttons. XInput is rarely used by most apps (and most X servers), and there're lots of programs out there now that would fail if you mapped the mousewheel to different buttons, since it's a de facto standard to have them on buttons 4 and 5.
Drives me nuts when people say fundamentally incorrect things with authority, since they always get modded "Insightful."
--ryan.
Oh, stop saying this. It didn't stop me from shipping Unreal Tournament 2004 without a single line of code that is Gnome, KDE, Red Hat, Ubuntu, Gentoo, or Suse (or whatever) specific. I figured (at least, I hoped) if there WERE issues in a given desktop or distro, the distro would make changes to support a popular game, but in practice, this never needed to happen. We used SDL (which is really the Gold Standard on Linux now, like DirectX would be on Windows), and OpenAL, which hid all sorts of other platform differences under the hood. Loki_setup handled installation across all distros for us, and we didn't worry about package managers.
UT2004 was probably my most popular endeavor, but there are lots of other games I've shipped with similar experiences.
People don't support Linux for a number of reasons, and while one of them is almost certainly the belief that Linux is terribly "fractured," in reality, it's not even remotely a problem...at least not in terms of shipping a game.
So stop spreading the belief.
--ryan.
Tell that to Ted Kennedy.
--ryan.
...has been working great for me, for several commercial games like Unreal Tournament 2004. Over the past five years, I've shipped several products using it, both on commercial CDs and downloadable installers.
:) Yes, trying to make distro-specific packages is SO BAD as to make this a better option...even between the various RPM-based distros.
It _is_ a little quirky in some regards, but once you get it working, it pretty much works everywhere.
If you use it, please use our codefork at http://icculus.org/loki_setup/, since the Loki Games version died with Loki, and we've put several man months of further development into it since (largely improving things as we ship new software with previously unexpected requirements, a MacOS X port, more archive formats and other enhancements). We're pretty fast to respond when someone has a bug, too.
Otherwise, I'd say give people a tarball and let them sort it out.
Someone DID mention that it's nice to enable those distros to repackage it in their preferred format, if there's a want, and I think that's an interesting idea as long as you don't rely on people to show up and do it. Gentoo, for instance, provides their own packages for most of the games I've shipped, which will even extract the data off the retail CDs if need be, etc...this empowers Gentoo users to have a consistent experience, but they can still use my loki_setup based installer if they want, as can those without a "real" distro package. This seems to be the least-messy solution at the moment, and it allows the distro maintainers to compete on features while you maintain a single, decent and universal solution yourself.
At least, this works well for me. Your mileage may vary.
--ryan.
Hi, I was the one that ported Unreal Tournament 2004 to the Mac...among other games. I'm probably qualified to speak to this.
There's an urban legend that Apple has a zero-tolerance policy for games. If you're an Apple employee writing a video game in your spare time, that's grounds for dismissal. Rumor is that this is not enforced, but still in the employee manual (or stone tablets outside 1 Infinite Loop or something).
This is probably not true, but it says a lot about the culture at Apple. Games are not in the business plan. At all. Since the Apple II was so wickedly ahead of everyone else in terms of game capabilities, a lot of people saw it as a "game system" or...well, a toy. Funny how that sort of thing blows up in your face, huh? So there's a historical bias against it at the upper levels. It's a flinch reaction. Several layers of upper management are going to have to retire or die (or both) before this attitude changes.
That being said, this article is pitching a silly (and unoriginal) idea. It's hard enough trying to evangelise the Mac to game publishers, but it gets even harder when Big Publisher starts asking the very legitimate question: "How come Apple put time, money, and manpower into porting Half-Life 2 and wants me to shoulder the port for my own title?"
A fair question, to be sure. Other results would be less concern at the original gamehouse for portability (we'll let Apple fix that) and the choking off of the few companies that are actually doing this today. Oh, and we haven't even gotten to the "could this even be profitable for Apple" question yet.
That being said, here're a few things Apple CAN be doing:
1) Get more developer relation people that do nothing but deal with games. These are the people game developers call when they need something done...OS bugs that need someone to fight for developer priority, hardware access, questions about marketing your product and general connecting of the right people. They also go to game developers/publishers to pitch the Mac and encourage them to see a profitable business model in Apple's platform. Apple used to have two of these people working this job. They now have one. I would bet that they'll have zero before 2005 is over. I suspect that the position is the red-haired stepchild of the company. I respect Rich for every day he gets up and continues to choose to go to work.
2) Backport OpenGL fixes. Apple's GL team is top-rate, but once they are working on a new release, you are out of luck. This is company policy, not the GL team's fault. Let me illustrate this for you. Right now you might be desperately trying to get a game running for Christmas, ported from a DirectX9-based game, and lo and behold, you find that a Pixel Shader you moved over to GL_ARB_vertex_program triggers a kernel panic in OSX. You get the team to look at it promptly, thanks to that one devrel soldier who's still standing, and it gets fixed, but the fix is rolled into Tiger.
Well, Tiger's not shipping for 6+ months, and you ain't shipping this Christmas. And when you do ship, you'll be telling a bunch of people that you need to buy a 150$ upgrade to the OS to play. This is more acceptable for Big Name Games, since somehow people will swallow this, albeit unhappily, when it's UT2004 or World of Warcraft. Will they swallow it for an indie game that's a 15 dollar, online-only purchase?
I'll be fair and say that, as far as I can tell, the overwhelming majority of Mac users upgrade to the latest OS anyhow, because generally the MacOS upgrades have been significantly compelling. When I screw up a Linux build in the year 2004 and a game stops running on a Red Hat 6.0 install from 1999, I get angry email. When ut2003 required people to upgrade to Jaguar, I never got a single bug report or complaint. Figure that one out. Still, if there is no upgrade path at all, you're timetable gets screwed. Put that shit in Software Update, Apple!
3) Give out free hardware, and give it out gratuitously. The Games Department (t
I have to throw in on this topic, since I've been doing this for several years now.
First, contracting is roughly akin to prostitution. You might think you're escaping some sort of pimp/whore relationship by not working for A Big Company, but you really are doing the same thing, just for multiple bosses. To be perfectly honest, you're trading a safety net for the possibility of more income.
That safety net is damned important, though. A lot of people don't have the stomach to function without it. There's nothing wrong with that, though.
Things like "health benefits" and "401k plans" and stuff go right out the window. You better get some health insurance out of your own pocket. (Listen to me...You Better Get Some Health Insurance!)
The people turning the Cogs of American Capitalism as 9-to-5 coders aren't as dumb as you suggest. Many of them are brilliant and talented, and they are focusing on building interesting things. Someone else is worried about finding revenue for them to do so.
And blahblahblah, money isn't everything.
So here's what I think: it's not the idea of a "normal job" that offends you. It's the idea of a boring job you can't stand. You don't want to maintain someone's else's shitty code, you don't want to write some buzzword crap pie that is neither spectacular nor innovative. I suspect that making someone else money is really secondary...it's a sour grapes response for being relegated to mediocrity.
Yeah, I can dig that.
So for you, based on the paragraph of you that I know, I would say: find an interesting job. I know, easier said than done, especially in this market. But there's bound to be something out there. Take some interviews (take them regardless of what else you do), and find the company that is building something interesting, and failing interesting, find the company that is building something beautiful. There's a lot of edification in elegance.
Ok, so about contracting.
Here's my advice. Find a vertical market.
My first paying jobs were writing Java code when no one did that. Later, when I was out of college and looking for work so I could be a Normal Person, I landed a job doing Linux and Mac development, because no one did that, but I did it for fun in my spare time, so I was naturally qualified for a job that couldn't be filled. If you're spending time on any open source project of any weight, chances are you are in a similar position. I just had the luxury of poverty...Linux was my primary OS out of need, but it paid off when command lines and C code and kernel builds were second nature to me. If you take these things for granted, that's good for you, and something you should try to convey in job interviews and contract pitches. Employers want smart people that can pick up new things above all else, right?
So I went to work for a company in Orange County doing Linux video games (you might have heard of them). When they went out of business, I moved in with my parents (turning in my membership card in the Normal Person Society), and started doing Linux and Mac game development, on my own, for companies that needed it. You know what? Nobody else did that. Now everyone needs a Mac port or a Linux dedicated server...people call me and ask if I'm available. I've been jokingly introduced at trade shows as "The Linux Game Industry". Vertical market, baby.
I don't live with my parents anymore, but I never got my membership in the Normal Person Society renewed. I guess that's a happy ending.
There are _always_ markets where people will pay top dollar for talented individuals. In the 90s, it was Java, and Linux, and embedded stuff, etc, but you can pull out any number of good examples for any era.
The world is filled with unemployed Visual Basic coders that took a college course on it because they heard there was money in it. It is _trivial_ to stand out from the herd. This is NOT measured in how many programming languages you know, but by what you can do, what you can pick up o
I aim to please. :)
--ryan.
Converting a number between floating point and integer on Macs is actually quite expensive compared to x86 systems. Converting between double and float has a severe penalty, too.
// An untested example: // force out of register. // store. // read.
Also, Macs tend to suffer a worse penalty for CPU cache misses.
Then again, there's a handful of general purpose registers on an x86, and 64 of them on the PPC (96 if you count the Altivec registers), so it's assumed that x86 systems will optimize for these cases more than the PPC, whereas the PPC assumes you'll load what you need into registers, work on it, and go back to RAM only when absolutely forced to. This means you should define a bunch of local variables, and load as much as possible into them at the start of a function. On the PPC, this can be several orders of magnitude faster, whereas on the x86, it might be a little slower (since those locals won't translate into registers, you end up shuffling between the heap and stack and working out of RAM anyhow).
Pre-G5, there's no square root instruction on the CPU. You can fake it with the fsqrtre opcode (which all Macs have, but I believe is optional in the PPC spec, too), but this gives you extremely low precision (five bits...you can actually GUESS with more precision!), but it's fast (and frequently "good enough" after two rounds of newton-raphson)...we used this (with Newton-Raphson) in UT2003/UT2004 without any noticable rendering artifacts. The G5 has a real, full-precision square root instruction, which spanks the cheap reciprocal method to boot, but will crash your program (SIGILL) on a G4 or lower. If you just call the system's C library's sqrt(), it'll do the right thing based on the running CPU, but to give you real precision, it won't using the reciprocal opcode...so on a G5, sqrt() gives good performance, on a G4, it'll eat up tons of CPU. The flyby intro on the original Unreal Tournament was spending about 17-20% of it's CPU time in sqrt() until I swapped in the reciprocal version.
While I'm talking about sqrt(), a lot of other things developers take for granted on their x86 floating point unit, like sin(), aren't implemented in hardware on the PPC.
Division on the PPC causes a complete pipeline stall (use multiplication where possible). GCC doesn't appear to optimize this case behind the scenes at this point.
On the G5, instructions are broken up into "dispatch groups"...usually five instructions, I think, but it varies due to a few factors. If you write to a memory address and read it back in the same dispatch group, it causes a pipeline stall. This is called an "LSU reject". Developer documentation says that in these cases you should either move the store and load to seperate dispatch groups, or at least pad out the dispatch group with no-ops so the load will be in a different group. GCC doesn't doesn't necessarily optimize this for you at this point, but I'm not sure where Apple's GCC branch lies in relation to the mainline version (which can now handle this).
LSU rejects are, however, a somewhat common optimization gotcha:
static int myvar1;
myvar1 = somefunc();
int myvar2 = myvar1 + 10;
The solution is to move the addition down a few lines of code so that the compiler doesn't put it in the same dispatch group...padding out with no-ops isn't really practical, and it's something the compiler should be doing anyhow. More to the point, your x86 developer isn't going to think something as harmless as having those two lines next to each other would be an optimization issue. Why should he?
Optimizations "truths" of the x86 aren't necessarily true on the PowerPC, either:
1) Loop unrolling is generally believed to be a "good optimization" on the x86, but it thrashes your instruction cache on the PPC. Actually, this is probably true on modern x86 chips nowadays, too, but on the PPC, Cache Is King.
2) Lookup tables are generally believe
Mesa is not anywhere near "reasonably fast" without hardware support. Software Mesa renders a frame every few seconds. Pixomatic can get 70 to 100 fps in many scenes. Then again, Mesa is meant to be a correct OpenGL implementation, whereas Pixomatic is concerned with speed over quality (and isn't an OpenGL API at all).
--ryan.
Beyond some minor convenience functions, the major thing we took from ROTT was the sound code...which, ironically, I wrote for Duke3D.
...although hats off to Jonathon Fowler, who did his own port of everything from scratch for Windows: http://jonof.edgenetwork.org/buildport/
Matt Saettler's EDUKE project was looking into moving to Windows using the icculus.org Build port, but the stumbling block was the lack of sound code (since the Apogee Sound System was a direct-to-hardware sort of thing).
So they sent me a header file and I reimplemented the audio library months ago. It was a pleasant surprise when ROTT was released that we finally had a testbed for that code (and a chance to clean out some bugs). This is also why ROTT was so functional so fast on Linux.
I think it's funny (and flattering) that there's a race between several win32 developers to get a WinDuke running...all but one of them is using the icculus.org port of the Build Engine to do it, and they STILL haven't kept pace with our Linux port.
--ryan.
...or Visual Basic. Seriously.
I have to say this, because someone recommended assembly language with a straight face.
Some things you should remember:
1) Programming languages are just an expression of a problem's solution. The less time you can spend learning to express, the more time you can be solving.
2) Teaching someone logic is really the goal at early stages. Teaching them how a computer works (i.e. - low level programming) is really just noise at the start. Teaching someone object orientation is problematic in the opposite direction.
3) Your mileage may vary by age. A ten year old learns VERY differently than an 11 year old.
4) You're probably a genious that learned to program by plowing through manuals and books and scouring the web. This makes you the exception to the rule. Most people do NOT learn this way.
5) Not everyone will be good at programming, ever, but everyone can make it further than Hello World...they can make it to the point where they are conscious that they are _creating_ something.
6) Most people benefit from immediate visual feedback. Teaching someone how to compile and link slows them down. Teaching someone to write to stdout slows them down. Slapping together something in Visual Basic and then showing them how to hook up responses gets them moving quickly, especially when they can hit F5 and see what happens immediately. VB adds other complexity, though, which makes something like LOGO better in terms of simplicity.
7) Not everyone wants to be a coding god. Some people just want to see what programming is, some people _think_ they are l33t hax0rs but don't know shit (you always get these in large classes), some people are there against their will (parents made them do it, etc)...just keep it simple and fun. Most people won't take this to be the start of a career in software development.
I used to teach programming courses for summer camps. Java is just totally inaccessible as a first language. I tried. Visual Basic actually worked very well. Object orientation is best explained by NOT explaining it (people will naturally understand what a "push button" is, but it's a waste of time to explain how it's "subclassed" from a "widget". These things can come later). Half the trick is not scaring them off in the first few weeks.
If there was a free Logo package that didn't suck, I'd have used that (maybe there is, I couldn't find one at the time, but that was years ago).
My response to it all was to develop Toby (http://icculus.org/toby/), which is a variation on Logo.
--ryan.
Ok, wait.
I'm the developer that did the 64-bit port of UT2003 (and the Linux port, and the Mac port...).
You need to keep two things in mind:
1) The OpenGL renderer is not as fast as the Direct3D renderer at this time. This is not the Athlon64's fault. You can see this on 32-bit Windows, since it can use both renderers. Since this is a Linux port of the game, we're using the GL renderer on the Athlon64 at this time.
2) The "stat fps" command isn't really a good benchmarking method.
3) This is a prerelease version of the game running on a prerelease version of SuSE running on prerelease drivers running on prerelease hardware. Please don't consider this "benchmark" to be representative!
--ryan.
I port video games to Linux for a living, so I am probably qualified to comment on this.
Do NOT optimize for Wine. You probably can't anyhow, since both Win32 (at least, DirectX) and Winelib are moving targets to varying degrees, what works and works well in one version of Wine will not necessarily do so in another.
I think Wine is an excellent piece of work, but I'd imagine even the Wine developers would rather have native Linux applications than emulated win32 apps (and if they don't, they should).
This is doubly true for game development, where you need every CPU cycle you can reasonably get.
Wine, Winelib, and WineX are really meant to be bridges to make Linux more feasible in the short term by letting Win32 programs run in some form, even if they just limp along. They are afterthought solutions to running software that we have no real ability to use, but think we can't do without.
The ideal solution is to write portable code in the first place. Be mindful of what you write, and follow some basic principles:
1) Don't tie yourself to a compiler. If you build on Visual C, take time to build on a different compiler (specifically, GCC) every now and then. Getting code to compile on various platforms is half the battle.
2) Don't tie yourself to a platform's API. Use cross-platform libraries and toolkits where you can, use abstraction layers in your own code where you can't. If you do this right, a good chunk of the porting work is just filling in stubs for a new platform. For game development, you should be looking at Simple Directmedia Layer for most of your needs. Other libraries like my own PhysicsFS can abstract file handling for you. OpenAL can give you 3D positional audio if SDL's stereo output is insufficient, and OpenGL gives you 3D accelerated graphics if SDL's 2D linear framebuffer is insufficient.
3) If PowerPC (MacOS, specifically) is of interest to you, be conscious of byte ordering. Always be conscious of structure packing regardless of platform. If 64-bit platforms (Alpha, Itanium, Hammer) are of interest to you in the future, don't do silly things like cast pointers to ints and such.
4) Don't use assembly code. Ever. If you _must_ use it, you better have a C fallback. Be smart and use NASM on win32 and Linux, so you don't have to deal with the massive differences in inline syntax between Visual Studio and GCC.
If you are more than one developer, the easiest way to do this is to have a devcrew made up of at least one person for each targeted platform. This makes it easy to make sure that things aren't silently breaking on MacOS while you write code for Win32, since that developer will catch it in his next code sync (you _are_ using source revision tools, right?).
Good luck to you.
--ryan.
The only thing I can find that is a (happy) Utopian novel is B.F. Skinner's Walden II, which is honestly a very interesting read. The book interested largely in the mechanics and psychology required for such a society, with just enough plot to keep Skinner's ideas moving.
I have been told that it was the basis for Brave New World in some form or another, but it might just be Skinner's ideas that Huxley was borrowing from/parodying.
I suppose you could count the original Walden (which has no relation to Walden II beyond the idea of utopia), but living alone doesn't qualify as Utopia...after all, the reasons that Utopias fall apart are...other people.
Sartre was right, after all.
Also, the concept of "Utopia" is usually written about for the sense of irony...reference 1984...plus we can find lots of stories like Animal Farm: good intentions turned to mud by human flaws. The point of Utopia, from a writers view, is to trample on it, generally. Take that for what it's worth.
--ryan.
The privilege separation code in OpenSSH 3.3 does not work with 2.2 Linux kernels.
It relies on mmap() semantics that aren't supported before kernel 2.4 (maybe 2.3.x). OpenSSH will configure, compile, and install successfully. It will start up, but it will NOT accept connections.
Your clients will get a "broken pipe" message, your syslog will get an "mmap: invalid parameter" message.
The solutions are:
I didn't see this anywhere until I dug into my syslog and then the OpenSSH mailing list. You have been warned.
If you do have kernel 2.4, you should read README.privsep in the openssh source distro, since you need to create a special directory and user/group for this (which also bit me in the butt...even if sshd had worked on 2.2, when I restarted it remotely, it didn't come back up because it didn't have that user...yeah, yeah, rtfm.
Good luck to everyone.
--ryan.
It's probably worth saying that just about any story falls into a few of Joseph Campbell's archetypes. Some fit more, some fit less, but no story I'm aware of fits them all. Indeed, some of the archetypes are contradictory.
:)
The notion that Luke Skywalker is a Campbellian hero apparently wasn't talked about until years after A New Hope was made. Still, that doesn't mean there aren't Campbellian elements...Anakin fits this, too. After he becomes Vader and his son overthrows him, it's likely that episodes 7, 8, and 9 would detail Luke's fall to the Dark Side, and another Jedi rising up to defeat him. It's cyclical, but that's part of the myth.
Some of these elements overlap with Spider-Man. Then again, maybe it's just a coming-of-age story with web-slingers. I dunno.
Here's my brief dissertation on the literary value of Spider-Man...hopefully I'll get less flames than Jon Katz.
--ryan.
Support Righteous Babe Records, Ani Difranco's indie label. They have a lot of high quality, frequently politically charged, and non-mainstream music. On top of that, the music doesn't suck.
None of that money goes to a big corporation; most of it goes back into making music and fighting the good fight, so to speak. If you want to put your money where your mouth is, go support Ani and the artists she publishes.
If you just want free music, you should get involved with etree.org, which is a community that distributes "bootlegs" of live concerts...the bootlegs are legal, recorded from performances of taper-friendly bands, such as Phish, older Grateful Dead shows, Bela Fleck...stuff like that. The bands that allow this tend to fit a certain profile (lots of improvising, etc), so if you don't like songs that can be fed to you in 3.5 minutes between commercials, you aren't going to like this avenue, however, there is a genuine community being fostered here that tends to be more artistic and intellectual, and frequently, very tight-knit for a bunch of virtual strangers. It's kind of cool, actually, and unlike the P2P mentality of leeching everything you can, there's a sense of the value of contributing back.
etree.org also happens to be Linux-friendly; there are links for XMMS plugins on the frontpage, etc.
The ultimate problem of these massive media corporations is they _do_ have a product that you want. I mean, if you want N'Sync (or that Episode 2 DVD, or some new Disney-owned Anime, etc...), then you can only get it in one place. I can also respect that not everyone is going to be falling over themselves for the latest release from indie band Bitch and Animal, but you _can_ consider this a chance to broaden your horizons; entertainment doesn't have to be mindless, and can in fact be a bettering activity.
Get out there and try something new.
--ryan.