At least in NPD's case, they take panelist's privacy very seriously. Really, in order to get people to answer all sorts of very specific questions without being very careful to prevent that information from being tied to specific users. Even if NPD _knew_ exactly which 1,000 panelists had 1,000+ illegal songs on their computers, it's worth more to them to retain panelist's trust (that forms the basis of their entire business) than to make the RIAA happy by turning them in.
'I wonder if clicking "I Agree" in any of thier software installations made them become "volunteers".'
NPD doesn't sneak software onto people's computers. People on NPD's panels know that they are panelists. They are recruited, surveyed (gender, age, etc.) and qualified into specific surveys, and are compensated for participating in the panels.
Of course, since the panelists know that they're on the panel, NPD has control mechanisms and statistical models to compensate in this surve, as they do when surveying what magazines people read, what food they like, and so on.I don't know the details of their methodology, but their research is trusted in a huge range of consumer surveys, and they've always had good answers to my questions, so my starting assumption is that they did a pretty good job on this survey as well, unless someone picks out specific flaws.
"For those of you who haven't paid attention to history, it was roughly two years between Reagan's big tax cuts and when tax receipts increased."
It was less than a year between Reagan's big tax cuts and Reagan's big tax increases. Those were the single largest tax increase in US history, incidentally, though the end result of a massive cut (that completely failed to generate new revenue) and the massive increase (to restore the revenue without which the government would have been wiped out) was still a small decrease from the previous taxes.
"people gave more money to charity before taxation became so fscking oppressive in this country." Right, but did total social spending go up or down? Quick answer -- up. When the government fund homeless shelters, etc., they're more consistent than private donors, though of course both are good.
"Operating systems are not an interchangeable commodity like they discuss in those economics textbooks."
This issue (lock-in) is exactly why monopolies distort the "level playing field" and need to have limits placed on their behavior. The Windows API and GUI tend to lock in application developers and users, because changing is hard/expensive, reinforcing the Windows monopoly.
So I agree with your point about the power of the Windows monopoly. But I disagree with the idea that this isn't something economists understand -- every monopolist (or even non-monopolists), even if they start with a pure commodity, tries to convert it to proprietary lock-on. Try to put a generic headlight into your Honda. Try to run a game not authorized by Sony or Nintendo or Microsoft on your video game console. This is hardly a new idea, or one unique to software.
Of course, there's the issue that the Constitution doesn't give the federal government the ability to regulate trade within a state, only between states.
Of course, now that the courts have decided that the federal government can apply other kinds of pressure on states (e.g. withold all highway funding), the federal government regulates all sorts of things that they probably shouldn't be able to...
"As an avid Linux user who doesn't use any Microsoft products, allow me to play devil's advocate here: Is Microsoft a monopoly?
Since I'm sitting here typing this on my Linux machine, my response is no.
If there is a viable alternative to a product, then how can said product have a monopoly? Some people need Windows to run certain critical applications, in fact almost all corporations do, but the alternative is there."
This is astoundingly missing the point. In economic terms, the issue is whether a company has "monopoly power" which means that it controls so much of the market that they can artificially control the market (i.e. inflate prices, suppress competition, etc.). This does not mean that it has 100% market share -- in many other markets, it's been sufficient that a single company controls more than 30% of a market to establish that it has "monopoly power". Given that Microsoft controls well over 90% of the desktop OS market, it's pretty clear that they have "monopoly power" in the desktop operating system market that gives them great leverage to suppress any competing operating system (witness the contracts that prohibited Windows OEM's from also shipping BeOS), and to leverage that monopoly in order to have an unfair advantage in other markets (witness the contracts with Windows OEM's that inhibited them from shipping Netscape).
The fact that there are some alternatives such as Linux that allow some users to avoid running Windows doesn't change the fact that MS could shut down any PC company at a whim by withdrawing its Windows license. If Microsoft had even 1/2 the desktop OS market, they'd still have "monopoly power" that would trigger limits on their behavior.
For a small company, I agree that any enterprise software would have to be a part of a systems integration deal with ongoing maintenance, not a straight software purchase, since as you point out they'd not have any IT department to support them.
I certainly didn't argue that open source was "best for every market" -- I argue that both open and closed source have different advantages and disadvantages for customers. I happen to agree that for typical desktops Windows (or MacOS) are better choices than Linux, becase they're _not_ functionally equivalent. Heck, my example was that there were good reasons to buy the Oracle database, which is not only proprietary but really expensive, so I don't regard myself as a promoter of open source in all cases. But when you buy closed source software you're dependent on your relationship with your vendor, more so than your dependence on an open source project's developer community, so you need contractual tools to give you leverage in that relationship. Sure, MS (for example) is great at responding to certain types of issues (e.g. helping you use their products as-is), but they're terrible at responding to others (e.g. they don't care about some bugs so they're not going to fix them, or they don't want to do what you want so they're never going to implement it). This is not specific to MS -- I've run into that with every software vendor I've ever used; it's simple reality that a vendor's agenda or resource allocation decisions may from time to time diverge from their customers. That's true with open source projects as well, but at least in that case there's a fall-back of paying someone to do what you need, which isn't an option for many commercial products. Or if it is an option, you're hit with insanely inflated professional services charges.
"most of the software licenses I've seen are very well balanaced"
I've been involved in $1M+ deals with many of the major software companies (MS, Oracle, Sun, Netscape, SAP, ATG, etc.), and in none of those cases did they start with a license that provided a meaningful warranty or committed to any response to bug reports, they want to be paid on delivery of the software rather than it working in production, etc. Of course, they're not out to screw their customers, but their starting point is that they're not legally committed to anything, so you're dependent on their goodwill (which gives them control). With most major vendors, I've run into situations where they didn't want to do what I needed them to do, and had to use the contract as leverage to get what I needed. Never lawsuits, but "discussions." That doesn't mean that proprietary software is bad -- it just means that you need to protect yourself in the negotiations over the license and other contractual terms. You have to negotiate to get yourself decent terms. If I were them, I might try the same trick -- no doubt many companies don't realize that they can negotiate, or don't catch everything, and that probably makes their lawyers happy because it limits exposure (e.g. if there's a real warranty, they have a liability on their books until the warranty expires). But it does mean that you have to be careful to protect yourself, because the standard contracts only protect the vendor, not the buyer (because the person who drafted it worked for the vendor, and his job is to protect his employer). None of this is to say that proprietary software is evil or shouldn't be used, just that you need to know what you're getting into.
That being said, smaller sofware companies are typically closer to their customers, and have better standard licenses, perhaps because they can't afford as many lawyers.
In a philosophical sense, I agree (somewhat), but in a pragmatic sense I think you're wrong.
While people have certainly been programming mobile agents in many languages for a very long time, there's nothing wrong with implementing them in Java. Java is a fairly nice language with a good security model and portable bytecode. Having used both to write agents, I can say that it's not quite as nice for writing mobile agents as Telescript (the language that General Magic designed for implementing mobile agents), but it's not bad. Sure, SmallTalk or Lisp are simpler and cleaner in many ways, and Erlang, etc., have some nice, though somewhat esoteric advantages, but Java has the fairly reasonable advantages that it's a widely known and extremely well supported language.
And as for preferring declarative programming to procedural programming, well, all I can say is that different models suit different kinds of problems, and different kinds of programmers. Changing both programming languages and programming paradigms (i.e. procedural to declarative) and throwing mobile agents into the mix) is extemely challenging to a development team. Not that it can't be done, but it's way harder (for a large team) than just introducing mobile agents implemented in a language everyone knows. Take one step at a time, or you lose people. I know, back in the 80's I was on a number of large Smalltalk projects, and making the leap to OOP, Client/Server and learning Smalltalk all at once was a barrier than many engineers couldn't hurdle. Sure, the stars got it, and were amazingly productive, but everyone else was blocked.
That being said, if you have a small team of stars, and a project that doesn't require a larger team, go for it -- you may be extremely successful. But I don't think that makes anyone who decides to implement mobile agents in Java wrong, just a little less daring.:-)
I don't know of any case where a software vendor was forced to provide more of a warranty than was in their software license.
Of course, there are other very good reasons to buy software from a company. For example, there's a certain security in storing your data in Oracle, as it works really well for a huge number of people. But being able to successfully sue Oracle (or Microsoft, or pretty much any software vendor) in the case of a software flaw shouldn't be something anyone should count on since it's never been done.
That being said, if you _pay_ for maintenance, you would have a leg to stand on. For example, if you pay for Gold level support, Oracle will provide you with a level of service that is stunning (I've had it -- it's worth the money if you really, really can't afford to lose data).
This is why you need to make a vendor warranty explicit -- without that you have no chance of getting them to respond to bugs unless they happen to be feeling nice. But when you (for example) have their source code in escrow, with release triggered on their inability to perform as documented, with well defined response times and a a liability limit of 3x purchase price, suddenly they take bug fixing seriously. Of course, you don't really want their source code or their money (because that would mean that your project failed, which should be worth more) -- it's a hammer to use on the vendor to get them to respond to you.
The phrase "someone to sue if the product doesn't work as specified" is worth some discussion.
First, of course, the obvious point -- all software is sold with disclaimers that the software isn't warranted to do anything, and that the vendor's liability is limited to the purchase price of the software.
So some advice -- if you can, negotiate a contract that warrants the software to perform as documented, with real financial penalties if the software doesn't work and the vendor can't fix it in a reasonable period of time. Remember, since you CAN'T fix the software, the vendor has to be commited to doing so. You can't get those terms on $299 consumer app's, but for "enterprise software" you've got some leverage to get un-screwed.
" *LIKE* open source, but the existing mechanisms for testing are really terrible, even if the bug repair response can be great. And since there's no accountability, there's little enforcement for responsibility...we KNOW that the developers of applciation X will probably fix that big hole in the security layer, but there's always the chance that they'll say "screw it, we want to work on the new stuff, fix it yourself." This is not the news you want to hear when a bug is holding up your business...that you will either have to hire an expensive programmer who knows the code, or a cheap programmer who will take weeks to get it done."
Just like proprietary software, open source software varies widely in its quality, and in the maturity of the development process. There are projects (like MySQL, Apache, gcc, Tomcat, Mozilla, etc.) that have astoundingly good regression test suites. Heck, check a change into the Mozilla source code tree and it'll automatically be compiled and regression tested (hundreds of tests) on all supported hardware and OS platforms, with a pretty web page pointing out who broke what when, not to mention a killer defect tracking database. Of course, there are also open source projects that aren't as mature, but then there are proprietary products with bad quality as well.
In my experience the code quality of open source projects is better than proprietary code, because the developers are more afraid of having "the world" see bad code than they are of having "their boss" see bad code. Peer pressure, in this case, is a wonderful thing. Also, engineers on open source projects are typically more responsive than in closed source software product companies, because they can be (no marketing or management barriers) -- only the smallest software companies are as responsive to customers as open source developers, for the same reason.
The 'danger' in using an open source project is that you might use a project without many other users, or have problems that nobody else cares about, in which case you'll have to fix it yourself. You can manage this by making sure that the project is active, and that your application is "typical." If you're company 1M using Apache, there's no risk. If you're company 1 using RandomProject, you're going to run into bumps. Of course, the same is true of proprietary software products, though it's a little harder to find out the real situation, particularly with small companies, so you have to do some digging.
The 'danger' is using a closed source product is that you can't fix the problems yourself, only beg a vendor to fix them (which they often charge professional service fees for!), if they decide to fix the problem at all, on their time schedule. You can manage this by making sure that you pay maintenance, and that you completely rewrite the software license to ensure that the product conforms to the documentation, and that there are response times and financial to give some teeth to make sure that the vendor has the right incentives to make you successful. Never, ever sign a software license as written by any software company -- they're absurdly slanted towards the vendor.
We can only hope that a vague title like "manager of technology strategy" means that this fool has no actual employees to manage, and no impact on anything that Princeton does or teaches its students. Aside from whether he's right or wrong, you'd think that Princeton would know better than to publish anything so badly written and lacking in either logic or supporting data. Apparently the.com crash didn't weed out all of the blather...
I'd say that this is a good parallel to the iTunes Music Store "FairPlay" DRM which prevents users from directly sharing purchased music files, but which is fairly easy to bypass for anyone mildly technical. It's enough DRM to keep the content companies happy, without really interfering with what people can do with the content.
Given the way that the 'flag' is defined, it should be trivial to engineer around it. Aside from it being simply a field in data transmitted in the clear, there are exceptions for obvious required cases like professional equipment. So this will serve as enough of a "speed bump" (by keeping non-technical folks from redistributing movies and TV shows using off-the-shelf consumer equipment) to make the media companies happy, but can be bypassed by professionals, hackers, etc.
The headline should read "Legal US Music Downloads Beat CD Single Sales".
The comparison implied by the "Legal US Music Downloads Beat CD Sales" is broken in several ways:
1) "Legal US Music Downloads" includes both album and single sales, while "CD Sales" refers only to CD Single sales. So it's not an "apples to apples" comparison.
2) "CD Sales" actually refers to CD Single sales, which are vanishingly small compared to actual CD sales (e.g. 2% according to Soundscan) so it's not only wrong, it's misleading by a factor of 50.
Digital download sales would need to grow by 50x to exceed CD sales. That would be great (for the labels, and musicians, etc.) but hasn't happened yet.
The headline should read "Legal US Music Downloads Beat CD Single Sales".
The comparison implied by the "Legal US Music Downloads Beat CD Sales" is broken in several ways:
1) "Legal US Music Downloads" includes both album and single sales, while "CD Sales" refers only to CD Single sales. So it's not an "apples to apples" comparison. 2) "CD Sales" actually refers to CD sales, which are vanishingly small compared to CD sales (e.g. 2% according to Soundscan) so it's not only wrong, it's misleading by a factor of 50.
Digital download sales would need to grow by 50x to exceed CD sales. That would be great (for the labels, and musicians, etc.) but hasn't happened yet.
Let's keep it in perspective -- since CD single sales are dwindling away to nothing, it's not too significant to point out that "X bypassed CD single sales". It's a catchy headline, I guess...
Note also that the reported number of tracks sold by digital download includes both tracks sold as 'singles' and tracks sold on 'albums.' Apple claims that 45% of the tracks sold on iTMS was on albums, so by extension that would imply that the sales of digital download singles is about 55% of the number of download tracks sold (Apple's not the only digital download song vendor, but let's assume that the others see similar behavior). That number still exceeds the number of CD singles sold, so I guess it doesn't change the headline...
Ringtone sales have also bypassed CD singles, by even greater numbers. It's amazing how well ringtones sell in Japan and Europe (as in "multi-billion dollar annual sales").
Actually, NT 3.x (and, possibly 4.0) ran on many CPU's including the PowerPC. If you remember back when the PPC was being promoted as the CPU of the Common Hardware Reference Platform, you could run MacOS, Linux, and NT on the same hardware. Anyway, I would hope that MS has retained that portability in the core of the OS (the same way Apple makes sure that MacOS X still runs on the x86) in order to keep its options open.
So it'd be easy for new "Xbox 2" games to run natively on PPC. That being said, they'd still need an x86 emulator to run the Xbox games. I bet a 2 GHz G5 could emulate an Xbox pretty well...
"You are talking out of your arse. Making games in all the genres wouldn't drive anyone away at all. The PS2 has a game in every genre, and that has the biggest 3rd party support out of all them.
And your marketting comment is stupid, as it is the same for ALL the console makers."
The PS2 has the biggest 3rd party support because (1) the PS2 has the biggest market share, and (2) Sony aggressively promotes third party developers. Since the Xbox is losing the marketshare war bady, you'd think that they'd be more aggressive in promoting sales of third party products instead of trying to capture all of the software revenue themselves. IMO, Nintendo pretty much proved that a console without third party support was doomed, no matter how good the first-party software is.
"The reason is MUST got through Microsofts system is so everything works together."
The question is whether you want all Xbox games to "work together" or whether you want all players of a game, across all consoles and operating systems, to "work together". Personally, I think that when people are playing Everquest they're thinking about playing Everquest, not that they're PS2 (or PC or Mac) owners, and it would be insane to require them to log into a Sony (or Microsoft or Apple) controlled online service.
"The chances of compatible cross-platform online titles are extremely remote anyway."
Actually, most cross-platform networked games are compatible across platforms.
OK, I stand corrected. So I'm still impressed, but I guess I should try again -- how about "a school starting a new supercomputer program can't afford to fail, even building a relatively cheap supercomputer." Is that better?:-)
"A 'supercomputer' is usually one that is optimized for vector operations"... While your definition of supercomputer is correct for traditional supercomputers, there are now many machines that are in effect huge piles of desktop computers connected by a really kick-ass network and router. So while each CPU may not be that great, the aggregate performance excceds any traditional vector supercomputer simply because it's not possible to make a single CPU 1000x as fast as a commodity CPU, but it's possible to buy 2000 commodity CPU's and get 50% of peak efficiency from them...
This is simply an amazing achievement. Plenty of people have built supercomputers from huge piles of x86's, but this team managed to not only pull the trick off in less time, for less money, but on a new hardware platform. I certainly follow their logic (PPC's have always been far better than x86's for real scientific-level precision FLOPs) but it's a really gutsy move betting your entire supercomputing program on a new CPU, new hardware platform, etc., and on your ability to get everything ported to the PPC -- that's a lot of risks to take, and a small school like that can't afford to fail, even building a relatively cheap supercomputer. But it clearly paid off! Not only did they get great PR for the university, they got a great computing resource for the students and faculty, and by doing it themselves rather than buying a complete system from a vendor, I am sure that those students all learned far more. And those 700 pizza and coke consuming students that cranked the code will all be able to say that they were part of this amazing thing.
"And as for the wireless LAN support - gak. GAK. Looking at that page made my brain hurt. That's just such a really really bad idea."
The part that scares me is that all of the commercial eVoting systems are so obviously flawed that I can't imagine how anyone ever bought them. Don't these towns have _anyone_ who can point out obvious flaws? It's not like it takes a rocket scientist to realize that combining a wireless LAN with voting just might increase the opportunity for fraud. Or that all of these systems have higher error rates and require more training (bad), yet cost far more, than scantrons.
Slashdot Mirror
At least in NPD's case, they take panelist's privacy very seriously. Really, in order to get people to answer all sorts of very specific questions without being very careful to prevent that information from being tied to specific users. Even if NPD _knew_ exactly which 1,000 panelists had 1,000+ illegal songs on their computers, it's worth more to them to retain panelist's trust (that forms the basis of their entire business) than to make the RIAA happy by turning them in.
'I wonder if clicking "I Agree" in any of thier software installations made them become "volunteers".'
NPD doesn't sneak software onto people's computers. People on NPD's panels know that they are panelists. They are recruited, surveyed (gender, age, etc.) and qualified into specific surveys, and are compensated for participating in the panels.
Of course, since the panelists know that they're on the panel, NPD has control mechanisms and statistical models to compensate in this surve, as they do when surveying what magazines people read, what food they like, and so on.I don't know the details of their methodology, but their research is trusted in a huge range of consumer surveys, and they've always had good answers to my questions, so my starting assumption is that they did a pretty good job on this survey as well, unless someone picks out specific flaws.
"For those of you who haven't paid attention to history, it was roughly two years between Reagan's big tax cuts and when tax receipts increased."
It was less than a year between Reagan's big tax cuts and Reagan's big tax increases. Those were the single largest tax increase in US history, incidentally, though the end result of a massive cut (that completely failed to generate new revenue) and the massive increase (to restore the revenue without which the government would have been wiped out) was still a small decrease from the previous taxes.
"people gave more money to charity before taxation became so fscking oppressive in this country." Right, but did total social spending go up or down? Quick answer -- up. When the government fund homeless shelters, etc., they're more consistent than private donors, though of course both are good.
"Operating systems are not an interchangeable commodity like they discuss in those economics textbooks."
This issue (lock-in) is exactly why monopolies distort the "level playing field" and need to have limits placed on their behavior. The Windows API and GUI tend to lock in application developers and users, because changing is hard/expensive, reinforcing the Windows monopoly.
So I agree with your point about the power of the Windows monopoly. But I disagree with the idea that this isn't something economists understand -- every monopolist (or even non-monopolists), even if they start with a pure commodity, tries to convert it to proprietary lock-on. Try to put a generic headlight into your Honda. Try to run a game not authorized by Sony or Nintendo or Microsoft on your video game console. This is hardly a new idea, or one unique to software.
Of course, there's the issue that the Constitution doesn't give the federal government the ability to regulate trade within a state, only between states.
Of course, now that the courts have decided that the federal government can apply other kinds of pressure on states (e.g. withold all highway funding), the federal government regulates all sorts of things that they probably shouldn't be able to...
"As an avid Linux user who doesn't use any Microsoft products, allow me to play devil's advocate here: Is Microsoft a monopoly?
Since I'm sitting here typing this on my Linux machine, my response is no.
If there is a viable alternative to a product, then how can said product have a monopoly? Some people need Windows to run certain critical applications, in fact almost all corporations do, but the alternative is there."
This is astoundingly missing the point. In economic terms, the issue is whether a company has "monopoly power" which means that it controls so much of the market that they can artificially control the market (i.e. inflate prices, suppress competition, etc.). This does not mean that it has 100% market share -- in many other markets, it's been sufficient that a single company controls more than 30% of a market to establish that it has "monopoly power". Given that Microsoft controls well over 90% of the desktop OS market, it's pretty clear that they have "monopoly power" in the desktop operating system market that gives them great leverage to suppress any competing operating system (witness the contracts that prohibited Windows OEM's from also shipping BeOS), and to leverage that monopoly in order to have an unfair advantage in other markets (witness the contracts with Windows OEM's that inhibited them from shipping Netscape).
The fact that there are some alternatives such as Linux that allow some users to avoid running Windows doesn't change the fact that MS could shut down any PC company at a whim by withdrawing its Windows license. If Microsoft had even 1/2 the desktop OS market, they'd still have "monopoly power" that would trigger limits on their behavior.
For a small company, I agree that any enterprise software would have to be a part of a systems integration deal with ongoing maintenance, not a straight software purchase, since as you point out they'd not have any IT department to support them.
I certainly didn't argue that open source was "best for every market" -- I argue that both open and closed source have different advantages and disadvantages for customers. I happen to agree that for typical desktops Windows (or MacOS) are better choices than Linux, becase they're _not_ functionally equivalent. Heck, my example was that there were good reasons to buy the Oracle database, which is not only proprietary but really expensive, so I don't regard myself as a promoter of open source in all cases. But when you buy closed source software you're dependent on your relationship with your vendor, more so than your dependence on an open source project's developer community, so you need contractual tools to give you leverage in that relationship. Sure, MS (for example) is great at responding to certain types of issues (e.g. helping you use their products as-is), but they're terrible at responding to others (e.g. they don't care about some bugs so they're not going to fix them, or they don't want to do what you want so they're never going to implement it). This is not specific to MS -- I've run into that with every software vendor I've ever used; it's simple reality that a vendor's agenda or resource allocation decisions may from time to time diverge from their customers. That's true with open source projects as well, but at least in that case there's a fall-back of paying someone to do what you need, which isn't an option for many commercial products. Or if it is an option, you're hit with insanely inflated professional services charges.
"most of the software licenses I've seen are very well balanaced"
I've been involved in $1M+ deals with many of the major software companies (MS, Oracle, Sun, Netscape, SAP, ATG, etc.), and in none of those cases did they start with a license that provided a meaningful warranty or committed to any response to bug reports, they want to be paid on delivery of the software rather than it working in production, etc. Of course, they're not out to screw their customers, but their starting point is that they're not legally committed to anything, so you're dependent on their goodwill (which gives them control). With most major vendors, I've run into situations where they didn't want to do what I needed them to do, and had to use the contract as leverage to get what I needed. Never lawsuits, but "discussions." That doesn't mean that proprietary software is bad -- it just means that you need to protect yourself in the negotiations over the license and other contractual terms. You have to negotiate to get yourself decent terms. If I were them, I might try the same trick -- no doubt many companies don't realize that they can negotiate, or don't catch everything, and that probably makes their lawyers happy because it limits exposure (e.g. if there's a real warranty, they have a liability on their books until the warranty expires). But it does mean that you have to be careful to protect yourself, because the standard contracts only protect the vendor, not the buyer (because the person who drafted it worked for the vendor, and his job is to protect his employer). None of this is to say that proprietary software is evil or shouldn't be used, just that you need to know what you're getting into.
That being said, smaller sofware companies are typically closer to their customers, and have better standard licenses, perhaps because they can't afford as many lawyers.
In a philosophical sense, I agree (somewhat), but in a pragmatic sense I think you're wrong.
:-)
While people have certainly been programming mobile agents in many languages for a very long time, there's nothing wrong with implementing them in Java. Java is a fairly nice language with a good security model and portable bytecode. Having used both to write agents, I can say that it's not quite as nice for writing mobile agents as Telescript (the language that General Magic designed for implementing mobile agents), but it's not bad. Sure, SmallTalk or Lisp are simpler and cleaner in many ways, and Erlang, etc., have some nice, though somewhat esoteric advantages, but Java has the fairly reasonable advantages that it's a widely known and extremely well supported language.
And as for preferring declarative programming to procedural programming, well, all I can say is that different models suit different kinds of problems, and different kinds of programmers. Changing both programming languages and programming paradigms (i.e. procedural to declarative) and throwing mobile agents into the mix) is extemely challenging to a development team. Not that it can't be done, but it's way harder (for a large team) than just introducing mobile agents implemented in a language everyone knows. Take one step at a time, or you lose people. I know, back in the 80's I was on a number of large Smalltalk projects, and making the leap to OOP, Client/Server and learning Smalltalk all at once was a barrier than many engineers couldn't hurdle. Sure, the stars got it, and were amazingly productive, but everyone else was blocked.
That being said, if you have a small team of stars, and a project that doesn't require a larger team, go for it -- you may be extremely successful. But I don't think that makes anyone who decides to implement mobile agents in Java wrong, just a little less daring.
"But those terms can be challenged in court."
I don't know of any case where a software vendor was forced to provide more of a warranty than was in their software license.
Of course, there are other very good reasons to buy software from a company. For example, there's a certain security in storing your data in Oracle, as it works really well for a huge number of people. But being able to successfully sue Oracle (or Microsoft, or pretty much any software vendor) in the case of a software flaw shouldn't be something anyone should count on since it's never been done.
That being said, if you _pay_ for maintenance, you would have a leg to stand on. For example, if you pay for Gold level support, Oracle will provide you with a level of service that is stunning (I've had it -- it's worth the money if you really, really can't afford to lose data).
This is why you need to make a vendor warranty explicit -- without that you have no chance of getting them to respond to bugs unless they happen to be feeling nice. But when you (for example) have their source code in escrow, with release triggered on their inability to perform as documented, with well defined response times and a a liability limit of 3x purchase price, suddenly they take bug fixing seriously. Of course, you don't really want their source code or their money (because that would mean that your project failed, which should be worth more) -- it's a hammer to use on the vendor to get them to respond to you.
And it works. I speak from experience...
The phrase "someone to sue if the product doesn't work as specified" is worth some discussion.
First, of course, the obvious point -- all software is sold with disclaimers that the software isn't warranted to do anything, and that the vendor's liability is limited to the purchase price of the software.
So some advice -- if you can, negotiate a contract that warrants the software to perform as documented, with real financial penalties if the software doesn't work and the vendor can't fix it in a reasonable period of time. Remember, since you CAN'T fix the software, the vendor has to be commited to doing so. You can't get those terms on $299 consumer app's, but for "enterprise software" you've got some leverage to get un-screwed.
" *LIKE* open source, but the existing mechanisms for testing are really terrible, even if the bug repair response can be great. And since there's no accountability, there's little enforcement for responsibility...we KNOW that the developers of applciation X will probably fix that big hole in the security layer, but there's always the chance that they'll say "screw it, we want to work on the new stuff, fix it yourself." This is not the news you want to hear when a bug is holding up your business...that you will either have to hire an expensive programmer who knows the code, or a cheap programmer who will take weeks to get it done."
Just like proprietary software, open source software varies widely in its quality, and in the maturity of the development process. There are projects (like MySQL, Apache, gcc, Tomcat, Mozilla, etc.) that have astoundingly good regression test suites. Heck, check a change into the Mozilla source code tree and it'll automatically be compiled and regression tested (hundreds of tests) on all supported hardware and OS platforms, with a pretty web page pointing out who broke what when, not to mention a killer defect tracking database. Of course, there are also open source projects that aren't as mature, but then there are proprietary products with bad quality as well.
In my experience the code quality of open source projects is better than proprietary code, because the developers are more afraid of having "the world" see bad code than they are of having "their boss" see bad code. Peer pressure, in this case, is a wonderful thing. Also, engineers on open source projects are typically more responsive than in closed source software product companies, because they can be (no marketing or management barriers) -- only the smallest software companies are as responsive to customers as open source developers, for the same reason.
The 'danger' in using an open source project is that you might use a project without many other users, or have problems that nobody else cares about, in which case you'll have to fix it yourself. You can manage this by making sure that the project is active, and that your application is "typical." If you're company 1M using Apache, there's no risk. If you're company 1 using RandomProject, you're going to run into bumps. Of course, the same is true of proprietary software products, though it's a little harder to find out the real situation, particularly with small companies, so you have to do some digging.
The 'danger' is using a closed source product is that you can't fix the problems yourself, only beg a vendor to fix them (which they often charge professional service fees for!), if they decide to fix the problem at all, on their time schedule. You can manage this by making sure that you pay maintenance, and that you completely rewrite the software license to ensure that the product conforms to the documentation, and that there are response times and financial to give some teeth to make sure that the vendor has the right incentives to make you successful. Never, ever sign a software license as written by any software company -- they're absurdly slanted towards the vendor.
We can only hope that a vague title like "manager of technology strategy" means that this fool has no actual employees to manage, and no impact on anything that Princeton does or teaches its students. Aside from whether he's right or wrong, you'd think that Princeton would know better than to publish anything so badly written and lacking in either logic or supporting data. Apparently the .com crash didn't weed out all of the blather...
I'd say that this is a good parallel to the iTunes Music Store "FairPlay" DRM which prevents users from directly sharing purchased music files, but which is fairly easy to bypass for anyone mildly technical. It's enough DRM to keep the content companies happy, without really interfering with what people can do with the content.
Given the way that the 'flag' is defined, it should be trivial to engineer around it. Aside from it being simply a field in data transmitted in the clear, there are exceptions for obvious required cases like professional equipment. So this will serve as enough of a "speed bump" (by keeping non-technical folks from redistributing movies and TV shows using off-the-shelf consumer equipment) to make the media companies happy, but can be bypassed by professionals, hackers, etc.
The headline should read "Legal US Music Downloads Beat CD Single Sales".
The comparison implied by the "Legal US Music Downloads Beat CD Sales" is broken in several ways:
1) "Legal US Music Downloads" includes both album and single sales, while "CD Sales" refers only to CD Single sales. So it's not an "apples to apples" comparison.
2) "CD Sales" actually refers to CD Single sales, which are vanishingly small compared to actual CD sales (e.g. 2% according to Soundscan) so it's not only wrong, it's misleading by a factor of 50.
Digital download sales would need to grow by 50x to exceed CD sales. That would be great (for the labels, and musicians, etc.) but hasn't happened yet.
The headline should read "Legal US Music Downloads Beat CD Single Sales".
The comparison implied by the "Legal US Music Downloads Beat CD Sales" is broken in several ways:
1) "Legal US Music Downloads" includes both album and single sales, while "CD Sales" refers only to CD Single sales. So it's not an "apples to apples" comparison.
2) "CD Sales" actually refers to CD sales, which are vanishingly small compared to CD sales (e.g. 2% according to Soundscan) so it's not only wrong, it's misleading by a factor of 50.
Digital download sales would need to grow by 50x to exceed CD sales. That would be great (for the labels, and musicians, etc.) but hasn't happened yet.
Let's keep it in perspective -- since CD single sales are dwindling away to nothing, it's not too significant to point out that "X bypassed CD single sales". It's a catchy headline, I guess...
Note also that the reported number of tracks sold by digital download includes both tracks sold as 'singles' and tracks sold on 'albums.' Apple claims that 45% of the tracks sold on iTMS was on albums, so by extension that would imply that the sales of digital download singles is about 55% of the number of download tracks sold (Apple's not the only digital download song vendor, but let's assume that the others see similar behavior). That number still exceeds the number of CD singles sold, so I guess it doesn't change the headline...
Ringtone sales have also bypassed CD singles, by even greater numbers. It's amazing how well ringtones sell in Japan and Europe (as in "multi-billion dollar annual sales").
Actually, NT 3.x (and, possibly 4.0) ran on many CPU's including the PowerPC. If you remember back when the PPC was being promoted as the CPU of the Common Hardware Reference Platform, you could run MacOS, Linux, and NT on the same hardware. Anyway, I would hope that MS has retained that portability in the core of the OS (the same way Apple makes sure that MacOS X still runs on the x86) in order to keep its options open.
So it'd be easy for new "Xbox 2" games to run natively on PPC. That being said, they'd still need an x86 emulator to run the Xbox games. I bet a 2 GHz G5 could emulate an Xbox pretty well...
"You are talking out of your arse. Making games in all the genres wouldn't drive anyone away at all. The PS2 has a game in every genre, and that has the biggest 3rd party support out of all them.
And your marketting comment is stupid, as it is the same for ALL the console makers."
The PS2 has the biggest 3rd party support because (1) the PS2 has the biggest market share, and (2) Sony aggressively promotes third party developers. Since the Xbox is losing the marketshare war bady, you'd think that they'd be more aggressive in promoting sales of third party products instead of trying to capture all of the software revenue themselves. IMO, Nintendo pretty much proved that a console without third party support was doomed, no matter how good the first-party software is.
"The reason is MUST got through Microsofts system is so everything works together."
The question is whether you want all Xbox games to "work together" or whether you want all players of a game, across all consoles and operating systems, to "work together". Personally, I think that when people are playing Everquest they're thinking about playing Everquest, not that they're PS2 (or PC or Mac) owners, and it would be insane to require them to log into a Sony (or Microsoft or Apple) controlled online service.
"The chances of compatible cross-platform online titles are extremely remote anyway."
Actually, most cross-platform networked games are compatible across platforms.
OK, I stand corrected. So I'm still impressed, but I guess I should try again -- how about "a school starting a new supercomputer program can't afford to fail, even building a relatively cheap supercomputer." Is that better? :-)
Someone please moderate the parent post up for sheer informative coolness.
"A 'supercomputer' is usually one that is optimized for vector operations" ... While your definition of supercomputer is correct for traditional supercomputers, there are now many machines that are in effect huge piles of desktop computers connected by a really kick-ass network and router. So while each CPU may not be that great, the aggregate performance excceds any traditional vector supercomputer simply because it's not possible to make a single CPU 1000x as fast as a commodity CPU, but it's possible to buy 2000 commodity CPU's and get 50% of peak efficiency from them...
This is simply an amazing achievement. Plenty of people have built supercomputers from huge piles of x86's, but this team managed to not only pull the trick off in less time, for less money, but on a new hardware platform. I certainly follow their logic (PPC's have always been far better than x86's for real scientific-level precision FLOPs) but it's a really gutsy move betting your entire supercomputing program on a new CPU, new hardware platform, etc., and on your ability to get everything ported to the PPC -- that's a lot of risks to take, and a small school like that can't afford to fail, even building a relatively cheap supercomputer. But it clearly paid off! Not only did they get great PR for the university, they got a great computing resource for the students and faculty, and by doing it themselves rather than buying a complete system from a vendor, I am sure that those students all learned far more. And those 700 pizza and coke consuming students that cranked the code will all be able to say that they were part of this amazing thing.
Damn!
"And as for the wireless LAN support - gak. GAK. Looking at that page made my brain hurt. That's just such a really really bad idea."
The part that scares me is that all of the commercial eVoting systems are so obviously flawed that I can't imagine how anyone ever bought them. Don't these towns have _anyone_ who can point out obvious flaws? It's not like it takes a rocket scientist to realize that combining a wireless LAN with voting just might increase the opportunity for fraud. Or that all of these systems have higher error rates and require more training (bad), yet cost far more, than scantrons.
Nope, looks like they figured out (on the second try) how to disable anonymous login on an ftp server.
Let's hope this all lands in freenet soon.