I do work on large projects in the multi-hour range for a full rebuild, and the compile time is still pretty much the lowest priority in selecting a compiler. All things being equal, of course I'd like to have the fastest compiles possible. But more important than that is that I can write the code I need to write without dodging compiler bugs / shortcomings all day, and deliver a binary which is optimized well for the target.
You can adapt to slow compiles. Breaking the project up into libraries, for example. You can't readily adjust to other compiler problems.
Pfft. Fusion reactor, so passe. It's just a classic steam engine with a hotter fire, after all. We want something truly revolutionary! Something, I say!
I'm pretty sure the author wasn't actually referring to queued rendered frames, but rather "headroom" of rendering performance before the FPS dips to perceptible choppiness in times of high loading.
While it is annoying that legit OSS projects have extra hurdles to go through, I will sleep a little sounder at night knowing it is making it just that much harder for Symantec to snark up my relatives' boxen.
Taken as is, XP can work very well - for teams that are already strongly of that mindset.
However, typical development teams are not staffed by management based upon styles, ideologies, or personalities. It is often by things such as where they sit (seriously) and whether or not they just finished something. A group of 5 "resources" are put together and told to work. If you take 5 random people and try to get them to use XP well, I can pretty much guarantee things won't work terribly well. To be fair, any process is going to have trouble with the typical staffing methodology prevalent in the marketplace.
If you get a bunch of people who lean towards the XP style, use XP. Great. If not, use a different model. Tailor your process to the people. A process can be changed easily, people's personalities can not.
Slashdot Mirror
I believe it's due in the Xerothermic Xenomorph release.
Word.
I do work on large projects in the multi-hour range for a full rebuild, and the compile time is still pretty much the lowest priority in selecting a compiler. All things being equal, of course I'd like to have the fastest compiles possible. But more important than that is that I can write the code I need to write without dodging compiler bugs / shortcomings all day, and deliver a binary which is optimized well for the target.
You can adapt to slow compiles. Breaking the project up into libraries, for example. You can't readily adjust to other compiler problems.
Pfft. Fusion reactor, so passe. It's just a classic steam engine with a hotter fire, after all.
We want something truly revolutionary! Something, I say!
The restriction is for Windows RT, so isn't relevant to the discussion about Windows 8.
It means you're actively wondering how they're counting you as an active G+ user after you only logged into YouTube.
I'm pretty sure the author wasn't actually referring to queued rendered frames, but rather "headroom" of rendering performance before the FPS dips to perceptible choppiness in times of high loading.
While it is annoying that legit OSS projects have extra hurdles to go through, I will sleep a little sounder at night knowing it is making it just that much harder for Symantec to snark up my relatives' boxen.
Taken as is, XP can work very well - for teams that are already strongly of that mindset.
However, typical development teams are not staffed by management based upon styles, ideologies, or personalities. It is often by things such as where they sit (seriously) and whether or not they just finished something. A group of 5 "resources" are put together and told to work. If you take 5 random people and try to get them to use XP well, I can pretty much guarantee things won't work terribly well. To be fair, any process is going to have trouble with the typical staffing methodology prevalent in the marketplace.
If you get a bunch of people who lean towards the XP style, use XP. Great. If not, use a different model. Tailor your process to the people. A process can be changed easily, people's personalities can not.
I have to admit, if I were a Mozilla developer invited to Redmond, I would not drink the kool aid.