You are soooo missing the point. Sure the spec for the project is open, I'm talking about what they use to build the system, not the system itself. They go buy a license for the latest whiz-bang development platform from vendor X, and then 10 years later find that it's costing exponential amounts to integrate it with new systems, find developers to add features, upgrade to newer versions, etc. etc.
My point is simply that when you're writing software that ostensibly needs to last forever, the benefits of using the most mature and standardized technologies far outweighs the quick fix of a pre-packaged solution.
Your reply isn't addressing anything I'm saying at all. Essentially you are just saying that they are doing things the best way they can because it's cheaper to hack then to re-engineer. Well, you can add a hack today and tomorrow, but eventually something will break and the code is so mangled that no one can unravel the mess at which point re-engineering becomes more cost effective. I was addressing how government apps should be engineered at the beginning of the project to avoid these kind of problems.
Are you putting quotation marks around my nouns because you think I'm using them incorrectly or you just don't know what they mean? There is no need to 'add extra fields' for future expansion as a properly normalized database will support added fields quite well whenever they are added.
It's not about open-source zealotry (heck, the GPL may not be suitable for the needs of the government in some cases). It's just the simple fact that you need a platform that's gonna be around forever. Something under a BSD license is the most likely thing to stick around because it has a lot of value and anyone can use it. It doesn't matter how much clout the government has if a vendor goes belly up and its codebase with it.
Of course this type of problem could theoretically be solved through proper database normalization and standardized software platforms. Granted, there wasn't much hope of that in 1968, but this is exactly the kind of problem that open specifications are capable of solving.
At some point when a technology is mature, open standards should be developed and the open version should be used for long-lived government applications. This is really the only way that technology can ever last. It's a shame that industry smoke and mirrors continue to convince decision makers that the latest proprietary platform is the way to go rather than embracing open foundations and conceiving commercial software as value-added high-level layers.
I suppose it's bad business not to lock your customer into your entire platform, but we're starting to hit a wall with what commercial software can accomplish in terms of elegance and maintainability on a large scale. I know it's a lot to expect out of the government, but the public good is what it's supposed to be about, isn't it?
The only problem is that Spammers will be well aware of the methods that the most common email client/servers use and will use to filter spam and create workarounds. The best way for an individual to reduce spam is to find the best little-known spam filter (tricky proposition to be sure).
Well, at one point you said "64 bit processors can process twice as much data as 32 bit processors", or words to that affect. Which is a pretty meaningless statement without a time reference.
Actually it's clearly implied that he means per clock cycle. What's not clear about the CPU operating on 64 bits of data rather than 32? It should be noted that the AltiVec processor is essentially an on-chip 128-bit processor that can be used to optimize parellel calculations, so this already eats into some of the performance gains that 64-bit could theoretically achieve.
I'm pretty sure that the rate CPUs read from memory is actually limited by things like memory bandwidth and speed. I think most CPUs already fetch memory speculatively in chunks of 128bits or more, so I doubt that'd make much difference.
Yes, of the 'leaked' G5 specs circulating on the rumour circuit, the new Apple bus will run at 50% of processor speed. If that's true it will give a much bigger speed bump than 32->64bit could, and will do a lot more to level the playing field with x86 architecture. I wish I had bus speed specs handy, but I know Mac buses are slow these days.
You also have to remember that the size of the pointer type doubles. That can actually decrease efficiency - as pointed out in the article linked to in a sibling post, a lot of computation involves linked list traversal. The increased pointer size would cause greater amounts of data to need to be processed.
But remember that each structure has to be grabbed from memory before the next address can be found, so it's not as if we could fetch two 32-bit pointers in the same time it would take to get one 64-bit pointer. Not that it can't decrease performance in some (or many) cases, but the ability to process more data at once tends to end up being a benefit once the compilers are optimized.
It's hard to analyze performance without solid knowledge of the chip architecture, the compiler, and the nature of common programs and where speed bottlenecks lie. What I will say is that Intel's chips are built on a much higher level of pipelining complexity and compiler optimization. So theoretically I would expect the PowerPC to have much more room to grow in terms of clever engineering to increase performance for the most common applications. The question is who has better people and more development dollars?
And what kind of book would meet that type of user's need? Of course this book is not going to inform you of Mac OS X GUI idiosyncrasies, nor would a book like that be worth more than $5.
Anyone who knows how to use UNIX and Windows needs only do one thing to become proficient on a Mac: use it on a regular basis. Once you dedicate the week or so it takes to get used to OS X, then buy this book and you can read about the stuff for which a power user actually needs a reference.
In retrospect, this must be a very clever troll, and I bit.
OS X has excellent reliability and stability. Thankfully that's one thing BSD and NeXT helped them achieve from the get go. While I agree that eye candy is fluffy and useless, there is a HUGE issue in between those, and that is USABILITY.
OS X was criticized early on by MacOS fanatics who thought they changed too much. In retrospect some of the changes were good, and some were bad. Regardless, OS X still has a long way to go to reach it's usability potential. There's lots of room for aquafying CLI tools and subtle things like putting the date in the menubar clock. The screenshots show a lot of new meat to the OS, not just cosmetic changes. I don't know whether I agree with charging $100 for the upgrade, but I'll still pay and love it.
Maybe, but the question is: how much more profit do they make selling a complete system vs. a software package? There's no telling how much they'd lose in hardware sales, especially as the perceived value of an Apple box declines over time.
Getting the same smooth behaviour on Linux with an installable product would be a can of worms compared to simply shipping a pre-configured Darwin with OS X. This could dilute the brand if OS X Linux had major problems. There's no telling how much development time this would eat up, and with no predictable revenue increase it seems like an unreasonable risk.
And probably, the only people going to O'Reillys are people that probably don't need the book.
Huh? This isn't scientific, but I'd say that the VAST majority of people who need a Nutshell book already know who O'reilly are and don't equate a B&N bookshelf with what's available about computers.
Also, I've not been dissatisfied with Mac book selections at major booksellers. There's way more overlap in Windows books, and I prefer quality over quantity.
You can't have a business model based on supporting old hardware. That's what linux is for. It doesn't mean you're forced to upgrade. If you bought a G3, you should have bought it because you found it useful, not on the promise of future support. If after all these years of Apple ditching legacy hardware you haven't yet figured out the pattern, then spelling it out to you is probably a waste of time.
If you want a new system buy a new system. If you don't want one, stick with what you've got.
If you truly have static content, then of course you can just serve up generic pages. But I can tell you the number of Web sites that have changing content far outnumber the ones that are static (or at least they should if people would update their damn site already!).
Even if your pages are relatively static information, if you want to change the design for 100 pages, it becomes a real pain in the ass to manually go through and change them one by one. You can use SSI for a very small percentage of cases using a header and footer include, but something as simple as using a unique title on each page can increase the complexity and maintainability of such a solution VERY quickly.
On the other hand, you can use a flexible templating system for your static pages, and get all kinds of maintainability benefits. Throw in a halfway decent caching system and you can actually get decent performance AND easy maintenance.
I have been saying for years now that PHP design needs to be somewhat standardized so that we can all make our mods fit better.
Fit better with what? If you want a standard Web site, there's plenty of content management systems out there with a variety of module interfaces to choose from. If you want hard-core general purpose modules, look no further than PEAR.
If you're suggesting there ought to be something between those 2 then go ahead and start a project, but I think there's plenty of open-source infrastructure out there already.
If you're suggesting that there's a wide variety of PHP crap out there, then I agree wholeheartedly, but unfortunately there is no solution. The easier a language is to get into, the more beginners will release a bunch of crap for it. Your only option is to learn to sort through it.
Let's face it, by the time you've declared you classes, instanced everything a procedural approach would probably have executed and be wating for the next client...
It's already going to be twenty times slower than a custom Apache module in C. Performance is not the hallmark of interpreted scripting languages, development costs are. So if you're looking as whether you use classes or procedural scripts, the deciding factor is not going to be whether it took.01 seconds or.02 seconds to generate the page.
I don't see the need to introduce the performance sapping abstraction of setting up classes and so forth with web scripts.
Well then you've never built a large Web site with any kind of engineered infrastructure. Sure you can bust out a quick script to mail a form or something trivial like that, but suppose you have 50 forms and you want to keep track of who they mail to in a database, and you have 500 pages for which you want to generate bread crumbs and dynamic menus, then you have 5 designs that you may want to update without changing 50 pages at a time. Well you either better have a REALLY good naming scheme for all your functions, or you could use objects to namespace your functions and provide some kind of method to the madness. You could argue that such systems should be built in a more industrial language, but there is a HUGE niche for rapidly developed web apps with enough engineering to actually be useful for several years. Not all (or even most) complex Web sites have the huge audiences that merit extreme optimization.
Right, except for the book wasn't authored for the sole purpose of being posted to Slashdot. He probably picked the name envisioning the book in a laypeople's book shop somewhere.
For the record...
on
Myth II Updated
·
· Score: 4, Informative
For eveyone who thinks either:
a) it's awesome to see a game developer supporting a 5 year old game
or
b) why is/. posting a game update
This game is NOT being supported by the developers. The game was originally played on bungie.net which is no defunct (after M$ shut it down).
This is a community led support project. Probably the best example I've seen because not only have they updated the code, they've also recreated a free on-line gaming service. I'd say that is a major success story for an aging game community.
Also, for those of you not familiar with Myth (or Bungie games in general), this game is the most revolutionary RTS game as much today as it was in November 1997 when first released. I still haven't seen RTS game that comes close to the user interface and visceral intensity of this game. Although at first glance it appears similar to other games, don't be fooled. An expert Myth player can control a large army with a frightening amount of micro-management. The unit balance offers a WIDE variety of strategies and tactics to be effective, and in general the whole thing is so well designed that subtleties of the game continue d to emerge for years after it was developed.
My only regret is that the community has been reduced to a small pool of expert players and a slightly larger pool of rank-whoring players who only play one game type (generally one of the most boring). To me this game is dead, but I can never forget the greatness of Myth II in its prime. Check out Myth World Cup '99 for some of the best films ever.
Certainly money could be saved by not using Microsoft products, and assuming that the changeover costs would be acceptable, there is still one big question:
Would the lack of any Microsoft products deter more people than it attracts? That's really the big question, because while not being able to learn Microsoft stuff will definitely drive away a lot of people, it could theoretically attract a lot of the kind of people you want in your college.
It would be an interesting experiment, but I doubt that it would be an acceptable risk for an actual real-world college.
This makes me laugh. Where is the value of this new system supposed to come from? Experience dictates that people don't adopt new technological methods of doing things unless there is a marked value improvement. While downloading MP3s is marginally easier than buying a CD (on-line or otherwise), you get lower sound quality, no physical media, and no printed materials.
Even if the value of being able to buy one song at a time and burn your own customized CDs is a significant enough improvement to alter consumers' behaviour (which I think is debatable), the perceived value of such a service has been diluted by the ability to do that exact same thing for free for years!
These companies are in a rush to grab a potentially huge market, but their business plans SUCK because there is no added value. I propose that declining CD sales may have more to do with the ease of burning CDs than actual Internet filesharing. With the current music marketing model of revenues coming from a few multi-platinum albums, it becomes very easy for kids to burn each other CDs since they all want the same mass-consumed product.
One way to give themselves a bit more protection might be to try to diversify musical interests so it wouldn't be easy to share 'the hot album'. I'm not sure if it's feasible, but they could save a lot of money on production and advertising, and still garner some major hits through word of mouth sales (kids will do an awful lot of free promotion if you're clever).
Now I know I may be talking out my ass, but the point is that recycling old concepts and increasing the price is NOT going to be a succesful business model.
I think the elitism arises because scripting languages tend to be so easy to learn. Aside from basic technical intelligence, what really differentiates a good programmer is a lot of experience with the various algorithms, security issues, and obscure interrelations between various components.
The easier a language is to learn, the sooner someone can start writing code, and the more ignorant they likely are to important issues that could affect their program. So the elitism is based in the statistical reality of the relative low quality of scripts out there.
Of course, a programmer who discounts the usefulness of scripting languages or the skill of scripters outright due to that fact is incredibly ignorant and possibly has self-esteem related to others who have done more than just program computers in their past.
Suppose the FSF owned this patent, then sold it to M$ for a billion dollars and used the cash to fund a lawsuit to challenge the legality of Palladium's protection mechanism.
I wish the reviewer would discuss what exactly the books asserts will help the developers share risk with the client. Extreme programming may be a great way to tackle these projects, but it doesn't do anything in and of itself to share risk. The only real way to minimize risk is for both parties to have a mutual understanding of the development process regardless of what that may be. XP will at best only be truly understood by the developer; the client will not likely know what the proper test cases are. So whether you use XP or not, the success of the contract will depend on the ability of the developers to explain what the client needs to know at each step of development and be forthcoming about the reality of development. Problems commonly occur because both parties are unwilling or unable to put themselves in each others shoes. Whether we like it or not developers are the ones in the position to do this since understanding a marketing plan is a lot easier than understanding how software development works.
I think a hard-copy reference is always useful for beginners, regardless of the quality of on-line documentation. Existing open-source projects are a great way to see how things are done, but there you run into the problem of learning bad habits from poorly written/commented code.
Where books really fill in nicely is giving programmers a road map of how to develop their application to avoid common pitfalls. Of course, this all depends on the expertise of the author.
Insightful? This is just sour apples. Apple has contributed plenty of code to the OSS community. If they had cash reserves of 40 billion dollars then I would agree they could be doing more, but even so I still don't see why they have the obligation to carry the burden of the OSS community at any cost.
Yes, Apple is a company trying to make a profit same as any other. Big deal. Why do you hold them to a higher standard than every other company in the world? I don't buy Macs because of some high-minded socialist software ideal. I buy them because they make a product that lets me do what I do better.
Are you bitter because Apple has made a more popular Unix than Linux? It can't possibly have a negative effect. People who write open source software will continue to do so, Apple does not reduce their output. As for end users adopting OS X instead of Linux, it forces many software companies to support a system that is much closer to Linux rather than supporting only Wintel and cementing Microsoft's dominance. It is much easier to port from OS X to Linux, and that can only benefit the OSS community.
I'm sorry, but your assertion amounts to saying that developing good software is not fair unless it is open source. I for one appreciate good software whether it is OS or not.
It's been a long time since raw processing power was the dominant factor in my computing efficiency. Granted, as a Web designer/developer my graphics are smaller, and I am in text editors half the time, but most of the time my computer is still waiting for me to click.
Sure it would be nice to shave a few seconds off my file previewing, but it's the functionality of the applications that really speeds up my work. I am pretty objective about computing platforms, and before OS X came out, PCs and Macs seemed so close in functionality that the price/performance difference could not be ignored. However, with preemptive multi-tasking, unix shell, protected memory, out-of-the-box Apache and PHP, and of course BBEdit, it's impossible for me to imagine doing web development on any other platform right now.
I haven't used XP yet, but I certainly haven't heard anything very compelling about it. I know that PCs _can_ work great under the right circumstances, but ever since installing IE 6 and having my PCs hard drive get scrambled beyond recognition, the extra $1000 I pay for my Mac does not seem unreasonable. It's the price you pay for standardized hardware and a useable Unix GUI with big name apps. OS X lets me breathe a big sigh of relief.
I think it just depends on the temperment of your particular boss. I work in a marketing department with 4 non-techies (well, one is a graphic designer), and I LOVE the degree of control they give me. Of course, it only works because they trust me, but I would not trade it for a job working with techies anytime soon.
Slashdot Mirror
And how much money did Disney make off that movie and subsequent merchandising?
You are soooo missing the point. Sure the spec for the project is open, I'm talking about what they use to build the system, not the system itself. They go buy a license for the latest whiz-bang development platform from vendor X, and then 10 years later find that it's costing exponential amounts to integrate it with new systems, find developers to add features, upgrade to newer versions, etc. etc.
My point is simply that when you're writing software that ostensibly needs to last forever, the benefits of using the most mature and standardized technologies far outweighs the quick fix of a pre-packaged solution.
Your reply isn't addressing anything I'm saying at all. Essentially you are just saying that they are doing things the best way they can because it's cheaper to hack then to re-engineer. Well, you can add a hack today and tomorrow, but eventually something will break and the code is so mangled that no one can unravel the mess at which point re-engineering becomes more cost effective. I was addressing how government apps should be engineered at the beginning of the project to avoid these kind of problems.
Are you putting quotation marks around my nouns because you think I'm using them incorrectly or you just don't know what they mean? There is no need to 'add extra fields' for future expansion as a properly normalized database will support added fields quite well whenever they are added.
It's not about open-source zealotry (heck, the GPL may not be suitable for the needs of the government in some cases). It's just the simple fact that you need a platform that's gonna be around forever. Something under a BSD license is the most likely thing to stick around because it has a lot of value and anyone can use it. It doesn't matter how much clout the government has if a vendor goes belly up and its codebase with it.
Of course this type of problem could theoretically be solved through proper database normalization and standardized software platforms. Granted, there wasn't much hope of that in 1968, but this is exactly the kind of problem that open specifications are capable of solving.
At some point when a technology is mature, open standards should be developed and the open version should be used for long-lived government applications. This is really the only way that technology can ever last. It's a shame that industry smoke and mirrors continue to convince decision makers that the latest proprietary platform is the way to go rather than embracing open foundations and conceiving commercial software as value-added high-level layers.
I suppose it's bad business not to lock your customer into your entire platform, but we're starting to hit a wall with what commercial software can accomplish in terms of elegance and maintainability on a large scale. I know it's a lot to expect out of the government, but the public good is what it's supposed to be about, isn't it?
Day trading is back. Ready the Put options!
The only problem is that Spammers will be well aware of the methods that the most common email client/servers use and will use to filter spam and create workarounds. The best way for an individual to reduce spam is to find the best little-known spam filter (tricky proposition to be sure).
Well that or a new email protocol.
Not that I totally disagree with you, but...
Well, at one point you said "64 bit processors can process twice as much data as 32 bit processors", or words to that affect. Which is a pretty meaningless statement without a time reference.
Actually it's clearly implied that he means per clock cycle. What's not clear about the CPU operating on 64 bits of data rather than 32? It should be noted that the AltiVec processor is essentially an on-chip 128-bit processor that can be used to optimize parellel calculations, so this already eats into some of the performance gains that 64-bit could theoretically achieve.
I'm pretty sure that the rate CPUs read from memory is actually limited by things like memory bandwidth and speed. I think most CPUs already fetch memory speculatively in chunks of 128bits or more, so I doubt that'd make much difference.
Yes, of the 'leaked' G5 specs circulating on the rumour circuit, the new Apple bus will run at 50% of processor speed. If that's true it will give a much bigger speed bump than 32->64bit could, and will do a lot more to level the playing field with x86 architecture. I wish I had bus speed specs handy, but I know Mac buses are slow these days.
You also have to remember that the size of the pointer type doubles. That can actually decrease efficiency - as pointed out in the article linked to in a sibling post, a lot of computation involves linked list traversal. The increased pointer size would cause greater amounts of data to need to be processed.
But remember that each structure has to be grabbed from memory before the next address can be found, so it's not as if we could fetch two 32-bit pointers in the same time it would take to get one 64-bit pointer. Not that it can't decrease performance in some (or many) cases, but the ability to process more data at once tends to end up being a benefit once the compilers are optimized.
It's hard to analyze performance without solid knowledge of the chip architecture, the compiler, and the nature of common programs and where speed bottlenecks lie. What I will say is that Intel's chips are built on a much higher level of pipelining complexity and compiler optimization. So theoretically I would expect the PowerPC to have much more room to grow in terms of clever engineering to increase performance for the most common applications. The question is who has better people and more development dollars?
And what kind of book would meet that type of user's need? Of course this book is not going to inform you of Mac OS X GUI idiosyncrasies, nor would a book like that be worth more than $5.
Anyone who knows how to use UNIX and Windows needs only do one thing to become proficient on a Mac: use it on a regular basis. Once you dedicate the week or so it takes to get used to OS X, then buy this book and you can read about the stuff for which a power user actually needs a reference.
In retrospect, this must be a very clever troll, and I bit.
OS X has excellent reliability and stability. Thankfully that's one thing BSD and NeXT helped them achieve from the get go. While I agree that eye candy is fluffy and useless, there is a HUGE issue in between those, and that is USABILITY.
OS X was criticized early on by MacOS fanatics who thought they changed too much. In retrospect some of the changes were good, and some were bad. Regardless, OS X still has a long way to go to reach it's usability potential. There's lots of room for aquafying CLI tools and subtle things like putting the date in the menubar clock. The screenshots show a lot of new meat to the OS, not just cosmetic changes. I don't know whether I agree with charging $100 for the upgrade, but I'll still pay and love it.
Maybe, but the question is: how much more profit do they make selling a complete system vs. a software package? There's no telling how much they'd lose in hardware sales, especially as the perceived value of an Apple box declines over time.
Getting the same smooth behaviour on Linux with an installable product would be a can of worms compared to simply shipping a pre-configured Darwin with OS X. This could dilute the brand if OS X Linux had major problems. There's no telling how much development time this would eat up, and with no predictable revenue increase it seems like an unreasonable risk.
And probably, the only people going to O'Reillys are people that probably don't need the book.
Huh? This isn't scientific, but I'd say that the VAST majority of people who need a Nutshell book already know who O'reilly are and don't equate a B&N bookshelf with what's available about computers.
Also, I've not been dissatisfied with Mac book selections at major booksellers. There's way more overlap in Windows books, and I prefer quality over quantity.
You can't have a business model based on supporting old hardware. That's what linux is for. It doesn't mean you're forced to upgrade. If you bought a G3, you should have bought it because you found it useful, not on the promise of future support. If after all these years of Apple ditching legacy hardware you haven't yet figured out the pattern, then spelling it out to you is probably a waste of time.
If you want a new system buy a new system. If you don't want one, stick with what you've got.
If you truly have static content, then of course you can just serve up generic pages. But I can tell you the number of Web sites that have changing content far outnumber the ones that are static (or at least they should if people would update their damn site already!).
Even if your pages are relatively static information, if you want to change the design for 100 pages, it becomes a real pain in the ass to manually go through and change them one by one. You can use SSI for a very small percentage of cases using a header and footer include, but something as simple as using a unique title on each page can increase the complexity and maintainability of such a solution VERY quickly.
On the other hand, you can use a flexible templating system for your static pages, and get all kinds of maintainability benefits. Throw in a halfway decent caching system and you can actually get decent performance AND easy maintenance.
I have been saying for years now that PHP design needs to be somewhat standardized so that we can all make our mods fit better.
Fit better with what? If you want a standard Web site, there's plenty of content management systems out there with a variety of module interfaces to choose from. If you want hard-core general purpose modules, look no further than PEAR.
If you're suggesting there ought to be something between those 2 then go ahead and start a project, but I think there's plenty of open-source infrastructure out there already.
If you're suggesting that there's a wide variety of PHP crap out there, then I agree wholeheartedly, but unfortunately there is no solution. The easier a language is to get into, the more beginners will release a bunch of crap for it. Your only option is to learn to sort through it.
Let's face it, by the time you've declared you classes, instanced everything a procedural approach would probably have executed and be wating for the next client...
It's already going to be twenty times slower than a custom Apache module in C. Performance is not the hallmark of interpreted scripting languages, development costs are. So if you're looking as whether you use classes or procedural scripts, the deciding factor is not going to be whether it took .01 seconds or .02 seconds to generate the page.
I don't see the need to introduce the performance sapping abstraction of setting up classes and so forth with web scripts.
Well then you've never built a large Web site with any kind of engineered infrastructure. Sure you can bust out a quick script to mail a form or something trivial like that, but suppose you have 50 forms and you want to keep track of who they mail to in a database, and you have 500 pages for which you want to generate bread crumbs and dynamic menus, then you have 5 designs that you may want to update without changing 50 pages at a time. Well you either better have a REALLY good naming scheme for all your functions, or you could use objects to namespace your functions and provide some kind of method to the madness. You could argue that such systems should be built in a more industrial language, but there is a HUGE niche for rapidly developed web apps with enough engineering to actually be useful for several years. Not all (or even most) complex Web sites have the huge audiences that merit extreme optimization.
Right, except for the book wasn't authored for the sole purpose of being posted to Slashdot. He probably picked the name envisioning the book in a laypeople's book shop somewhere.
For eveyone who thinks either:
/. posting a game update
a) it's awesome to see a game developer supporting a 5 year old game
or
b) why is
This game is NOT being supported by the developers. The game was originally played on bungie.net which is no defunct (after M$ shut it down).
This is a community led support project. Probably the best example I've seen because not only have they updated the code, they've also recreated a free on-line gaming service. I'd say that is a major success story for an aging game community.
Also, for those of you not familiar with Myth (or Bungie games in general), this game is the most revolutionary RTS game as much today as it was in November 1997 when first released. I still haven't seen RTS game that comes close to the user interface and visceral intensity of this game. Although at first glance it appears similar to other games, don't be fooled. An expert Myth player can control a large army with a frightening amount of micro-management. The unit balance offers a WIDE variety of strategies and tactics to be effective, and in general the whole thing is so well designed that subtleties of the game continue d to emerge for years after it was developed.
My only regret is that the community has been reduced to a small pool of expert players and a slightly larger pool of rank-whoring players who only play one game type (generally one of the most boring). To me this game is dead, but I can never forget the greatness of Myth II in its prime. Check out Myth World Cup '99 for some of the best films ever.
Certainly money could be saved by not using Microsoft products, and assuming that the changeover costs would be acceptable, there is still one big question:
Would the lack of any Microsoft products deter more people than it attracts? That's really the big question, because while not being able to learn Microsoft stuff will definitely drive away a lot of people, it could theoretically attract a lot of the kind of people you want in your college.
It would be an interesting experiment, but I doubt that it would be an acceptable risk for an actual real-world college.
This makes me laugh. Where is the value of this new system supposed to come from? Experience dictates that people don't adopt new technological methods of doing things unless there is a marked value improvement. While downloading MP3s is marginally easier than buying a CD (on-line or otherwise), you get lower sound quality, no physical media, and no printed materials.
Even if the value of being able to buy one song at a time and burn your own customized CDs is a significant enough improvement to alter consumers' behaviour (which I think is debatable), the perceived value of such a service has been diluted by the ability to do that exact same thing for free for years!
These companies are in a rush to grab a potentially huge market, but their business plans SUCK because there is no added value. I propose that declining CD sales may have more to do with the ease of burning CDs than actual Internet filesharing. With the current music marketing model of revenues coming from a few multi-platinum albums, it becomes very easy for kids to burn each other CDs since they all want the same mass-consumed product.
One way to give themselves a bit more protection might be to try to diversify musical interests so it wouldn't be easy to share 'the hot album'. I'm not sure if it's feasible, but they could save a lot of money on production and advertising, and still garner some major hits through word of mouth sales (kids will do an awful lot of free promotion if you're clever).
Now I know I may be talking out my ass, but the point is that recycling old concepts and increasing the price is NOT going to be a succesful business model.
I think the elitism arises because scripting languages tend to be so easy to learn. Aside from basic technical intelligence, what really differentiates a good programmer is a lot of experience with the various algorithms, security issues, and obscure interrelations between various components.
The easier a language is to learn, the sooner someone can start writing code, and the more ignorant they likely are to important issues that could affect their program. So the elitism is based in the statistical reality of the relative low quality of scripts out there.
Of course, a programmer who discounts the usefulness of scripting languages or the skill of scripters outright due to that fact is incredibly ignorant and possibly has self-esteem related to others who have done more than just program computers in their past.
Suppose the FSF owned this patent, then sold it to M$ for a billion dollars and used the cash to fund a lawsuit to challenge the legality of Palladium's protection mechanism.
I wish the reviewer would discuss what exactly the books asserts will help the developers share risk with the client. Extreme programming may be a great way to tackle these projects, but it doesn't do anything in and of itself to share risk. The only real way to minimize risk is for both parties to have a mutual understanding of the development process regardless of what that may be. XP will at best only be truly understood by the developer; the client will not likely know what the proper test cases are. So whether you use XP or not, the success of the contract will depend on the ability of the developers to explain what the client needs to know at each step of development and be forthcoming about the reality of development. Problems commonly occur because both parties are unwilling or unable to put themselves in each others shoes. Whether we like it or not developers are the ones in the position to do this since understanding a marketing plan is a lot easier than understanding how software development works.
I think a hard-copy reference is always useful for beginners, regardless of the quality of on-line documentation. Existing open-source projects are a great way to see how things are done, but there you run into the problem of learning bad habits from poorly written/commented code.
Where books really fill in nicely is giving programmers a road map of how to develop their application to avoid common pitfalls. Of course, this all depends on the expertise of the author.
Insightful? This is just sour apples. Apple has contributed plenty of code to the OSS community. If they had cash reserves of 40 billion dollars then I would agree they could be doing more, but even so I still don't see why they have the obligation to carry the burden of the OSS community at any cost.
Yes, Apple is a company trying to make a profit same as any other. Big deal. Why do you hold them to a higher standard than every other company in the world? I don't buy Macs because of some high-minded socialist software ideal. I buy them because they make a product that lets me do what I do better.
Are you bitter because Apple has made a more popular Unix than Linux? It can't possibly have a negative effect. People who write open source software will continue to do so, Apple does not reduce their output. As for end users adopting OS X instead of Linux, it forces many software companies to support a system that is much closer to Linux rather than supporting only Wintel and cementing Microsoft's dominance. It is much easier to port from OS X to Linux, and that can only benefit the OSS community.
I'm sorry, but your assertion amounts to saying that developing good software is not fair unless it is open source. I for one appreciate good software whether it is OS or not.
It's been a long time since raw processing power was the dominant factor in my computing efficiency. Granted, as a Web designer/developer my graphics are smaller, and I am in text editors half the time, but most of the time my computer is still waiting for me to click.
Sure it would be nice to shave a few seconds off my file previewing, but it's the functionality of the applications that really speeds up my work. I am pretty objective about computing platforms, and before OS X came out, PCs and Macs seemed so close in functionality that the price/performance difference could not be ignored. However, with preemptive multi-tasking, unix shell, protected memory, out-of-the-box Apache and PHP, and of course BBEdit, it's impossible for me to imagine doing web development on any other platform right now.
I haven't used XP yet, but I certainly haven't heard anything very compelling about it. I know that PCs _can_ work great under the right circumstances, but ever since installing IE 6 and having my PCs hard drive get scrambled beyond recognition, the extra $1000 I pay for my Mac does not seem unreasonable. It's the price you pay for standardized hardware and a useable Unix GUI with big name apps. OS X lets me breathe a big sigh of relief.
I think it just depends on the temperment of your particular boss. I work in a marketing department with 4 non-techies (well, one is a graphic designer), and I LOVE the degree of control they give me. Of course, it only works because they trust me, but I would not trade it for a job working with techies anytime soon.