I think the most significant line in the slashdot article is this:
"But having the option to install Firefox, say, is useless unless people know what it is."
But Glyn then goes on to suggest some kind of publicity campaign, which misses the point of this entire inane EU process. Because if a publicity campaign were useful, it should be done regardless of this ruling.
The average user does not, and continues to not, care. For those of us who do care, we know how to install Firefox and don't need Microsoft or the European governments to hand-hold us through the process. This EU process been one big, fat waste of time.
Even if Microsoft offers a version of Windows that lets users choose explicitly to install IE or Firefox (and I guess, what, Opera as well? Safari? Chrome?), I bet you good money that most users will choose "Microsoft Internet Explorer" because it has Microsoft in the title. As in, faced with this bogus non-option, an ignorant user will choose the program that was written by the operating system vendor.
And I mean this bet literally, because when I write web browser plugins I make sure they support IE first. It's the browser most people have because most people don't care. Until and unless the EU makes Microsoft bundle Firefox to the exclusion of IE---a move that hardly seems fair by any rational metric---most users will still use the most convenient option, because most users simply don't care. End of story.
An advertising campaign that would sell Firefox needs to begin by making people care about their web browser as an application, then explain why Firefox is a better application for browsing the web. History suggests it's an uphill battle.
Incidentally, the fortune file entry at the bottom of my article listing right now is "bureaucracy, n: A method for transforming energy into solid waste." How appropriate.
I had a pair of very good professors for freshman physics in college. They were heavily into using computers to simulate the classic experiments; we had several labs where we would build computer simulations using VPython (http://vpython.org/) and then compare the results generated by the simulation with the data generated in the original laboratory experiments.
Of these projects, my favorite was the Rutherford gold-foil experiment, a.k.a. Geigerâ"Marsden experiment (http://en.wikipedia.org/wiki/Geiger-Marsden_experiment). The simulation basically involved floating an "atomic nucleus" in space and then firing "alpha particles" at the nucleus with a uniformly-distributed random offset in the y-axis. Running a thousand alpha particles past the nucleus and then plotting their vertical displacement when the horizontal displacement exceeded a meter gave a stiatistical distribution matching the original experiment.
But the interesting trick to the whole simulation: running it slowly made it easy to see the alpha particles deflect as they interacted with the electric field of the gold nucleus. But cranking the rate of simulation up until several alpha particles were created and deflected per second created an interesting visual effect: the particles were no longer bending away from the nucleus, they were bouncing off of an invisible "surface" of average minimum distance. For me, this was the first time I gained an intuitive grasp of the relationship between electric fields and the reason I can't pass my hand through a table's surface.
These sorts of experiments are subtle and difficult to reproduce with real instruments, but their results are profound. I highly recommend computer simulation to iron out the complexities of real-world hardware.
That is a very good point. My original question disregarded non-essential travel, imagining fuel as a fixed-consumption good. This is what I meant when I referred to it as a 'staple;' I'm unfortunately failing to recall the term for a good with an inflexible rate of consumption.
However, even though fuel is not fixed-consumption, it seems that this policy would also depress travel; taxing the mileage should discourage people from traveling in a similar way to taxing the fuel.
A better question would be "Wouldn't taxing miles instead of fuel also bend the market and depress travel? If it would, why not just keep taxing fuel, since we already have a system in place to do so?"
It seems to me that if you tax a staple good, and people will be consuming less of that staple good due to an increase in efficiency... meaning you'll bring in less money from those taxes...
Then you raise the tax. What's the downside? It's not like people are going to consume less gas if the tax goes up.
Arguably, cranking the tax could also lead to people holding onto junker cars for sentimental reasons replacing them or repairing their engines. So really, it's win-win.
Yes, this is essentially the explanation I've heard---the collapse of the dot-com boom led disproportionately more women to abandon the field / not enter the field than men.
I'd be interested in the why's of that, however, Any information on that side of the issue?
In all fairness, you can buy a new game for $12 and less today. The downloadable content channels (XBLA, WiiWare, etc.) have allowed the game developers to cut out the brick-and-mortar distribution channel and pass the cost savings on to the consumer. That's what makes downloadable content so great.
But if people think that they're "nickel-and-dimed" by $6 content, maybe it becomes more economically sensible to jack the cost up to $50 again? That's why I can't fathom what people are thinking when they complain about getting "nickel-and-dimed" by games that cost less than games on a store shelf.
All you're saying is that you aren't willing to spend $16 on a new Megaman game that features the sliding and Mega Buster game mechanics, and the option to play as Protoman.
That's up to you, but if I recall correctly I spent more than $16 on Megaman 3, back in the day.
Oh, excellent! Good work; someone should get the word out.
I won't make use of it myself (my XO runs Sugar because I'm not a student and I bought the laptop partially because of its default OS installation). But if I hear anyone expressing frustration about Sugar's "out-there"-ness, I'll point them in the direction of the Ubuntu distro.
So when can we expect Ubuntu on the XO laptops? I'd support that.
I own an XO with Sugar installed. I like the system's UI metaphor, but it is exceedingly different from the common Windows / Mac / X11-with-the-popular-WM metaphors. For that reason alone, I could see educators wanting children to learn a more mainstream system; teaching them something as avant-garde as Sugar risks sending them out into the real world without sufficient practical knowledge.
Keep in mind that the "learn the underlying concepts, the rest is just detail" concept of computer education only works for a subset of students. The rest really do need to be shown explicitly what button to push, and going from Sugar's desktop to the Windows desktop when they leave school could put them at a severe market disadvantage against students who learned Windows, Ubuntu, Mac OS X, or another traditional desktop metaphor and suite of applications.
It's not that it's a Windows world so much as that it's a windowed world. Sugar is pretty far out there.
While I respect the attitude that one should stick up for what one believes in, this particular boycott will be futile in the long-run. Quite frankly, Microsoft's XBLA has shown the viability of locked licenses on the XBox 360, and I fail to see why they are not a reasonable business strategy on the PC---just another gaming platform. EA has seen the handwriting on the wall regarding this business model, and the fact that it isn't what PC gamers are accustomed to doesn't matter to them. There's a very real possibility that this will become the de facto standard for the big-name players.
Boycott if you feel it's right. Just be prepared to have that boycott extend to all big-publisher PC games... And then understand that the average user isn't going to care enough to not go out and purchase Madden 2010.
Yeah, this is a situation where US distribution mostly falls flat-on-its-face.
I don't know the whole story, but my understanding is that GameStop has the US market pretty much wired down for first-day delivery. Due to the deals they have with publishers, if you aren't them or a handful of other big-name stores, the publishers won't even ship you the game on day 1 because they want to go with channels that have a proven track record.
Amazon being added to the set of big names for the publishers is a big step forward for them.
I'm honestly surprised; Google's previous beta rollouts have, to my memory, been a lot more functional at first unveiling. This new system is seriously broken... I can't put more than one person in a room (no idea why, as others seem to have no trouble), it's slow, it's limited, and it has serious user interface design issues.
Google will have to move fast if they want to compete in this space. There are, quite frankly, too many options for social interactive chat right now; the only thing Google has going for it in this market is name recognition.
I think we see so many sites put their 'useful' interactivity in flash for the same reason as the Browser Wars days... It still takes effort to maintain cross-browser compatibility and look-and-feel in a Web 2.0 application.
Flash code is maintained compatible by all the browsers running the same flash engine, which Adobe has a vested interest in keeping compatible across architectures. Sounds like a good opportunity for me to write a piece of code once and only once, which I'd jump at.
You're absolutely right, and I misused the term "model."
When I said "model," I was referring to the aggregate of the actual model and the way the model is exposed for the average consumer (who in WindowsXP, is usually running as an administrator for even the simplest tasks, either due to poorly-written software or their account simply having been configured by default as an administrator). There is just too much software in Windows XP that wants administrator privileges for questionable reasons---so much that it's easier for me to just run as administrator and ignore the issue altogether.
But I do have to ask whether this is totally the fault of the developers. I'm a developer myself, and I've experimented with running as a non-administrator. Simply being forced to "Run as..." most of my development applications was enough to make me want to re-enable administrator privileges on my personal account. But I was effectively forced to re-privilege myself when I began developing an IE plugin. If there is a way to register ActiveX controls with the system as a non-administrator so that Internet Explorer can find and use them correctly, I am unaware of it. IE's reliance on ActiveX means that you effectively can't download and install plugins from the Internet without admin rights---even in such a way that the execution of those plugins would be at a non-administrator privilege level.
Incidentally, Firefox sidesteps this entire issue by allowing plugins to be downloaded into a user's Application Data directory.
So the WindowsXP security model is fairly robust as a model. But with software written by Microsoft themselves not taking advantage of it in a way that makes the end user's life convenient, there's certainly something that smells. Even if the only real substantive difference between the Windows XP and Vista security models is the addition of a more convenient on-the-fly escalation mechanism, that's saying something.
(I don't know how my example of grabbing ActiveX plugins from the Internet works in Vista under UAC. If someone has experience with it, I'm interested)
With respect to the iReboot team (who seem to have written a pretty nifty piece of software and certainly know their way around programming), there is so much spin on this article that light passing near it bends.
The "Gory details" portion of the article gives a pretty good explanation of the work they had to do to make iReboot access high-permission OS features via a low-permission client. I have no idea how they got from there to "Any program that UAC blocks from starting up 'for good security reasons' can be coded to work around these limitations with (relative) ease." What they seem to be missing is that there was an installer in the loop---an installer that requires admin privileges. This is exactly the part of the process that UAC is trying to force upon Windows developers!
The most significant problems with the Windows XP security model are as much social as technical. Because the model didn't make it easy to get "serious work" done as a non-administrator, most people are running as administrators most of the time. This creates a whole culture that is very vulnerable to social engineering---simple games are being run at the same permission level as complex drive-recovery utilities and keyboard loggers.
By having people run low-privilege by default and escalating when necessary, the UAC model forces developers to be a little clearer about what their applications are doing (since things that "just worked" in WinXP now require permission in Vista). My understanding is that the way iReboot works now is the way it should always have worked, under the Windows OS model; the fact that it also worked if the user were running as an administrator was a happy accident. How well did the old iReboot work if I wasn't running as an administrator? If the answer is "It didn't," then, well, maybe they were doing it wrong the whole time.
UAC has some problems, but the fact that it puts more work on developers isn't one of them. The work is necessary because it is accounting for a weaker security model from the past. And developers should know that security isn't free.
Our source-compile times were much larger than our make parsing times, but in the common case (where there was a single file to re-compile), the several seconds of delay that were added by all of the Makefile rules reporting in that they had nothing to do were noticeable. It's possible that this was not due to parsing the makefile but instead due to the need to complete the dependency evaluation, but if that were the case I don't understand why we saw such a significant speed-boost when we went to Python.
But I don't really have enough hard evidence to lay the blame at the fault of gmake's parser. It is more accurate to say "When we re-wrote the build scripts in Python, running them on an already-built (or nearly-built) project was notably faster than running the gmake scripts on an already-built (or nearly-built) project." It is possible that this was due to some other element of the end-to-end process (such as the way the different systems access files or query the OS for file metadata).
We looked into it, and scons is very good. The reason we didn't use it is because, ironically, it's too powerful (and relatedly complicated)---it gives a nifty complexity-for-power tradeoff that we simply decided we didn't want to leverage. Since we already knew exactly what we wanted our make process to do, we found it faster and easier to just write the Python script we wanted than to figure out the "scons way" to do things. Dependency management is a good example: scons offers automatic dependency walking, but we already had explicit dependency lists that we were comfortable updating, and didn't want to take the time to learn enough about the scons dependency walker to trust it.
If we'd been writing a make process on a brand new project, reading up on scons and understanding the structure it places upon your build process would have been a better choice. As it stands, we had a very specific plan, we could see it fairly clearly in "straight-line" python, and the instant scons's requirements got in the way we tossed it overboard and forged ahead.
especially beloved by system administrators and build managers.
Absolutely. This year we replaced an old build system written in make with a (vastly superior) Python solution written from scratch. The replacement took one programmer about two weeks. The make system had taken two programmers a disgusting amount of time to build and support. What suprised me most upon completing the changeover was that the Python solution was faster than the gmake solution; since Python compiles to bytecode, re-running the build script was a quicker operation than gmake's re-parsing of the make files.
Python's advantage as build glue is that it is just simple enough to be nearly shell scripting (write a simple wrapper, and you can pretty much just write shell script). But it has the features of a decent high-level language---including, most importantly, integrated documentation and a debugger. Anyone who doesn't understand why one would need a debugger for a build system hasn't yet written a build system complicated enough.
Really though, this is less a statement in support of Python and more a statement against gmake. Make's age really shows as a build language, and if not for all the tools in the GNU world that depend upon / assume the existence of a make engine, I would encourage everyone to just toss the whole thing overboard and create all new build scripts in something else. You have better things to do with your time than reverse engineer code written in a nearly incomprehensible string-parsing language by someone who---in spite of the "standards" that have built up around make over the years---has gone off and done his own thing anyway. If you're going to have to deal with custom build code, you may as well own the challenge completely.
In the case of Carnegie Mellon in particular, I remember the policy being that CMU will pass the information requested by the RIAA right through to them, and has explicitly told its student body that it will not shield them from investigation and prosecution. I wonder if these institutions were cherry-picked for having such policies. Can anyone comment on (a) whether CMU's policy is unchanged, and (b) whether the other schools operate to a similar strategy?
For every copy of Halo you fail to buy, I'm going to buy three.
I think the main reason this feature isn't happening is that it actually isn't a major desire of many, many Halo players. Personally, I'm in it for the story, the shared-box co-op, and the multiplayer competitive. I've seen the online co-op in Splinter Cell, and I was not impressed. Ubisoft has excellent developers, and their online co-op was plagued with trouble. If Bungie says there are technical hurdles, I believe them.
Online co-op would be nice, but it's not a deal-breaker for me.
I'm actually pretty happy with the system XBox Live already has built-in for reporting and denoting people who have various levels of tolerance of bad behavior. The four 'gated communities' and the "Prefer / avoid" mechanism have appeared to work well for me. Halo 3 will probably be one of the first games I've played with a big enough immature userbase to really test the system: If I stop hearing offensive language after a couple weeks playing it, I'll consider it a success.
Slashdot Mirror
I think the most significant line in the slashdot article is this:
"But having the option to install Firefox, say, is useless unless people know what it is."
But Glyn then goes on to suggest some kind of publicity campaign, which misses the point of this entire inane EU process. Because if a publicity campaign were useful, it should be done regardless of this ruling.
The average user does not, and continues to not, care. For those of us who do care, we know how to install Firefox and don't need Microsoft or the European governments to hand-hold us through the process. This EU process been one big, fat waste of time.
Even if Microsoft offers a version of Windows that lets users choose explicitly to install IE or Firefox (and I guess, what, Opera as well? Safari? Chrome?), I bet you good money that most users will choose "Microsoft Internet Explorer" because it has Microsoft in the title. As in, faced with this bogus non-option, an ignorant user will choose the program that was written by the operating system vendor.
And I mean this bet literally, because when I write web browser plugins I make sure they support IE first. It's the browser most people have because most people don't care. Until and unless the EU makes Microsoft bundle Firefox to the exclusion of IE---a move that hardly seems fair by any rational metric---most users will still use the most convenient option, because most users simply don't care. End of story.
An advertising campaign that would sell Firefox needs to begin by making people care about their web browser as an application, then explain why Firefox is a better application for browsing the web. History suggests it's an uphill battle.
Incidentally, the fortune file entry at the bottom of my article listing right now is "bureaucracy, n: A method for transforming energy into solid waste." How appropriate.
I had a pair of very good professors for freshman physics in college. They were heavily into using computers to simulate the classic experiments; we had several labs where we would build computer simulations using VPython (http://vpython.org/) and then compare the results generated by the simulation with the data generated in the original laboratory experiments.
Of these projects, my favorite was the Rutherford gold-foil experiment, a.k.a. Geigerâ"Marsden experiment (http://en.wikipedia.org/wiki/Geiger-Marsden_experiment). The simulation basically involved floating an "atomic nucleus" in space and then firing "alpha particles" at the nucleus with a uniformly-distributed random offset in the y-axis. Running a thousand alpha particles past the nucleus and then plotting their vertical displacement when the horizontal displacement exceeded a meter gave a stiatistical distribution matching the original experiment.
But the interesting trick to the whole simulation: running it slowly made it easy to see the alpha particles deflect as they interacted with the electric field of the gold nucleus. But cranking the rate of simulation up until several alpha particles were created and deflected per second created an interesting visual effect: the particles were no longer bending away from the nucleus, they were bouncing off of an invisible "surface" of average minimum distance. For me, this was the first time I gained an intuitive grasp of the relationship between electric fields and the reason I can't pass my hand through a table's surface.
These sorts of experiments are subtle and difficult to reproduce with real instruments, but their results are profound. I highly recommend computer simulation to iron out the complexities of real-world hardware.
So if this law gets properly enforced, it'll basically become economically infeasible to offer internet service in South Carolina?
If so, it seems like a problem that will correct itself when the state gets hit squarely in the pocketbook.
That is a very good point. My original question disregarded non-essential travel, imagining fuel as a fixed-consumption good. This is what I meant when I referred to it as a 'staple;' I'm unfortunately failing to recall the term for a good with an inflexible rate of consumption.
However, even though fuel is not fixed-consumption, it seems that this policy would also depress travel; taxing the mileage should discourage people from traveling in a similar way to taxing the fuel.
A better question would be "Wouldn't taxing miles instead of fuel also bend the market and depress travel? If it would, why not just keep taxing fuel, since we already have a system in place to do so?"
It seems to me that if you tax a staple good, and people will be consuming less of that staple good due to an increase in efficiency... meaning you'll bring in less money from those taxes...
Then you raise the tax. What's the downside? It's not like people are going to consume less gas if the tax goes up.
Arguably, cranking the tax could also lead to people holding onto junker cars for sentimental reasons replacing them or repairing their engines. So really, it's win-win.
Yes, this is essentially the explanation I've heard---the collapse of the dot-com boom led disproportionately more women to abandon the field / not enter the field than men.
I'd be interested in the why's of that, however, Any information on that side of the issue?
You can get computerized Solace, but I'm pretty sure it's only for Mac.
In all fairness, you can buy a new game for $12 and less today. The downloadable content channels (XBLA, WiiWare, etc.) have allowed the game developers to cut out the brick-and-mortar distribution channel and pass the cost savings on to the consumer. That's what makes downloadable content so great.
But if people think that they're "nickel-and-dimed" by $6 content, maybe it becomes more economically sensible to jack the cost up to $50 again? That's why I can't fathom what people are thinking when they complain about getting "nickel-and-dimed" by games that cost less than games on a store shelf.
All you're saying is that you aren't willing to spend $16 on a new Megaman game that features the sliding and Mega Buster game mechanics, and the option to play as Protoman.
That's up to you, but if I recall correctly I spent more than $16 on Megaman 3, back in the day.
Oh, excellent! Good work; someone should get the word out.
I won't make use of it myself (my XO runs Sugar because I'm not a student and I bought the laptop partially because of its default OS installation). But if I hear anyone expressing frustration about Sugar's "out-there"-ness, I'll point them in the direction of the Ubuntu distro.
So when can we expect Ubuntu on the XO laptops? I'd support that.
I own an XO with Sugar installed. I like the system's UI metaphor, but it is exceedingly different from the common Windows / Mac / X11-with-the-popular-WM metaphors. For that reason alone, I could see educators wanting children to learn a more mainstream system; teaching them something as avant-garde as Sugar risks sending them out into the real world without sufficient practical knowledge.
Keep in mind that the "learn the underlying concepts, the rest is just detail" concept of computer education only works for a subset of students. The rest really do need to be shown explicitly what button to push, and going from Sugar's desktop to the Windows desktop when they leave school could put them at a severe market disadvantage against students who learned Windows, Ubuntu, Mac OS X, or another traditional desktop metaphor and suite of applications.
It's not that it's a Windows world so much as that it's a windowed world. Sugar is pretty far out there.
While I respect the attitude that one should stick up for what one believes in, this particular boycott will be futile in the long-run. Quite frankly, Microsoft's XBLA has shown the viability of locked licenses on the XBox 360, and I fail to see why they are not a reasonable business strategy on the PC---just another gaming platform. EA has seen the handwriting on the wall regarding this business model, and the fact that it isn't what PC gamers are accustomed to doesn't matter to them. There's a very real possibility that this will become the de facto standard for the big-name players.
Boycott if you feel it's right. Just be prepared to have that boycott extend to all big-publisher PC games... And then understand that the average user isn't going to care enough to not go out and purchase Madden 2010.
Yeah, this is a situation where US distribution mostly falls flat-on-its-face.
I don't know the whole story, but my understanding is that GameStop has the US market pretty much wired down for first-day delivery. Due to the deals they have with publishers, if you aren't them or a handful of other big-name stores, the publishers won't even ship you the game on day 1 because they want to go with channels that have a proven track record.
Amazon being added to the set of big names for the publishers is a big step forward for them.
... because right now they're terrible.
I'm honestly surprised; Google's previous beta rollouts have, to my memory, been a lot more functional at first unveiling. This new system is seriously broken... I can't put more than one person in a room (no idea why, as others seem to have no trouble), it's slow, it's limited, and it has serious user interface design issues.
Google will have to move fast if they want to compete in this space. There are, quite frankly, too many options for social interactive chat right now; the only thing Google has going for it in this market is name recognition.
I think we see so many sites put their 'useful' interactivity in flash for the same reason as the Browser Wars days... It still takes effort to maintain cross-browser compatibility and look-and-feel in a Web 2.0 application.
Flash code is maintained compatible by all the browsers running the same flash engine, which Adobe has a vested interest in keeping compatible across architectures. Sounds like a good opportunity for me to write a piece of code once and only once, which I'd jump at.
You're absolutely right, and I misused the term "model."
When I said "model," I was referring to the aggregate of the actual model and the way the model is exposed for the average consumer (who in WindowsXP, is usually running as an administrator for even the simplest tasks, either due to poorly-written software or their account simply having been configured by default as an administrator). There is just too much software in Windows XP that wants administrator privileges for questionable reasons---so much that it's easier for me to just run as administrator and ignore the issue altogether.
But I do have to ask whether this is totally the fault of the developers. I'm a developer myself, and I've experimented with running as a non-administrator. Simply being forced to "Run as..." most of my development applications was enough to make me want to re-enable administrator privileges on my personal account. But I was effectively forced to re-privilege myself when I began developing an IE plugin. If there is a way to register ActiveX controls with the system as a non-administrator so that Internet Explorer can find and use them correctly, I am unaware of it. IE's reliance on ActiveX means that you effectively can't download and install plugins from the Internet without admin rights---even in such a way that the execution of those plugins would be at a non-administrator privilege level.
Incidentally, Firefox sidesteps this entire issue by allowing plugins to be downloaded into a user's Application Data directory.
So the WindowsXP security model is fairly robust as a model. But with software written by Microsoft themselves not taking advantage of it in a way that makes the end user's life convenient, there's certainly something that smells. Even if the only real substantive difference between the Windows XP and Vista security models is the addition of a more convenient on-the-fly escalation mechanism, that's saying something.
(I don't know how my example of grabbing ActiveX plugins from the Internet works in Vista under UAC. If someone has experience with it, I'm interested)
With respect to the iReboot team (who seem to have written a pretty nifty piece of software and certainly know their way around programming), there is so much spin on this article that light passing near it bends.
The "Gory details" portion of the article gives a pretty good explanation of the work they had to do to make iReboot access high-permission OS features via a low-permission client. I have no idea how they got from there to "Any program that UAC blocks from starting up 'for good security reasons' can be coded to work around these limitations with (relative) ease." What they seem to be missing is that there was an installer in the loop---an installer that requires admin privileges. This is exactly the part of the process that UAC is trying to force upon Windows developers!
The most significant problems with the Windows XP security model are as much social as technical. Because the model didn't make it easy to get "serious work" done as a non-administrator, most people are running as administrators most of the time. This creates a whole culture that is very vulnerable to social engineering---simple games are being run at the same permission level as complex drive-recovery utilities and keyboard loggers.
By having people run low-privilege by default and escalating when necessary, the UAC model forces developers to be a little clearer about what their applications are doing (since things that "just worked" in WinXP now require permission in Vista). My understanding is that the way iReboot works now is the way it should always have worked, under the Windows OS model; the fact that it also worked if the user were running as an administrator was a happy accident. How well did the old iReboot work if I wasn't running as an administrator? If the answer is "It didn't," then, well, maybe they were doing it wrong the whole time.
UAC has some problems, but the fact that it puts more work on developers isn't one of them. The work is necessary because it is accounting for a weaker security model from the past. And developers should know that security isn't free.
Our source-compile times were much larger than our make parsing times, but in the common case (where there was a single file to re-compile), the several seconds of delay that were added by all of the Makefile rules reporting in that they had nothing to do were noticeable. It's possible that this was not due to parsing the makefile but instead due to the need to complete the dependency evaluation, but if that were the case I don't understand why we saw such a significant speed-boost when we went to Python.
But I don't really have enough hard evidence to lay the blame at the fault of gmake's parser. It is more accurate to say "When we re-wrote the build scripts in Python, running them on an already-built (or nearly-built) project was notably faster than running the gmake scripts on an already-built (or nearly-built) project." It is possible that this was due to some other element of the end-to-end process (such as the way the different systems access files or query the OS for file metadata).
We looked into it, and scons is very good. The reason we didn't use it is because, ironically, it's too powerful (and relatedly complicated)---it gives a nifty complexity-for-power tradeoff that we simply decided we didn't want to leverage. Since we already knew exactly what we wanted our make process to do, we found it faster and easier to just write the Python script we wanted than to figure out the "scons way" to do things. Dependency management is a good example: scons offers automatic dependency walking, but we already had explicit dependency lists that we were comfortable updating, and didn't want to take the time to learn enough about the scons dependency walker to trust it.
If we'd been writing a make process on a brand new project, reading up on scons and understanding the structure it places upon your build process would have been a better choice. As it stands, we had a very specific plan, we could see it fairly clearly in "straight-line" python, and the instant scons's requirements got in the way we tossed it overboard and forged ahead.
especially beloved by system administrators and build managers.
Absolutely. This year we replaced an old build system written in make with a (vastly superior) Python solution written from scratch. The replacement took one programmer about two weeks. The make system had taken two programmers a disgusting amount of time to build and support. What suprised me most upon completing the changeover was that the Python solution was faster than the gmake solution; since Python compiles to bytecode, re-running the build script was a quicker operation than gmake's re-parsing of the make files.
Python's advantage as build glue is that it is just simple enough to be nearly shell scripting (write a simple wrapper, and you can pretty much just write shell script). But it has the features of a decent high-level language---including, most importantly, integrated documentation and a debugger. Anyone who doesn't understand why one would need a debugger for a build system hasn't yet written a build system complicated enough.
Really though, this is less a statement in support of Python and more a statement against gmake. Make's age really shows as a build language, and if not for all the tools in the GNU world that depend upon / assume the existence of a make engine, I would encourage everyone to just toss the whole thing overboard and create all new build scripts in something else. You have better things to do with your time than reverse engineer code written in a nearly incomprehensible string-parsing language by someone who---in spite of the "standards" that have built up around make over the years---has gone off and done his own thing anyway. If you're going to have to deal with custom build code, you may as well own the challenge completely.
In the case of Carnegie Mellon in particular, I remember the policy being that CMU will pass the information requested by the RIAA right through to them, and has explicitly told its student body that it will not shield them from investigation and prosecution. I wonder if these institutions were cherry-picked for having such policies. Can anyone comment on (a) whether CMU's policy is unchanged, and (b) whether the other schools operate to a similar strategy?
The number of people going to see the new "Harry Potter" movie continues to rise, while the viewership of "The Lord of the Rings" stays flat.
For every copy of Halo you fail to buy, I'm going to buy three.
I think the main reason this feature isn't happening is that it actually isn't a major desire of many, many Halo players. Personally, I'm in it for the story, the shared-box co-op, and the multiplayer competitive. I've seen the online co-op in Splinter Cell, and I was not impressed. Ubisoft has excellent developers, and their online co-op was plagued with trouble. If Bungie says there are technical hurdles, I believe them.
Online co-op would be nice, but it's not a deal-breaker for me.
"Time to go back to school and learn a useful skill?"
I'm actually pretty happy with the system XBox Live already has built-in for reporting and denoting people who have various levels of tolerance of bad behavior. The four 'gated communities' and the "Prefer / avoid" mechanism have appeared to work well for me. Halo 3 will probably be one of the first games I've played with a big enough immature userbase to really test the system: If I stop hearing offensive language after a couple weeks playing it, I'll consider it a success.