I think they need evidence that a crime has been committed or is in the process of being committed, and that the person they want to track is involved in that crime. That last part especially is one they seem to want to skip.
My suspicion: Calc is holding a parsed XML document tree for the spreadsheet in memory, while Excel reduces it to an internal structure and recreates the XML when saving. Holding the document tree makes for more memory usage, but it allows for preserving of unknown XML without mangling it. Parsing to an internal structure is more efficient, but anything not recognized will be lost when saving.
NB: I don't think Calc works on the parsed XML, it probably has an internal representation to actually work on which is then tied back into the XML document so the XML can be updated to reflect the changes in the data.
I left a job earlier this year. Money wasn't the main reason I left, there were several more important issues that led me to even considering an offer in the first place, but by taking a job elsewhere I got a better than 20% raise. The iteration before that my salary stayed about the same but I got myself moved to a much better area of the country. The iteration before that I got out of a literally dead-end area and got a 30% raise in the process.
I think we're just going through an adjustment. For much of the 20th century you got raises by staying with one company a long time. As people got used to stability companies started to adjust by offering smaller and smaller raises, counting on unwillingness to risk the instability of a job hunt to keep workers from leaving. Workers have to adjust by accepting that raises now will come by shifting jobs, either to a radically different position within the company or more likely to a different company altogether. If you recognize that, you can get an advantage by looking for your next job while still employed. That's the playing field the companies seem to want, so the only real question is are you going to look for the most advantageous strategy for yourself or not?
Of course, in a couple of decades when workers have come to consider job-hopping the status quo, companies will begin to offer large raises and other benefits to try and keep employees around long-term and cut turnover costs. Or maybe they'll find some other strategy. The critical thing isn't what'll happen, but to be able to spot the trend early and follow it instead of lagging it.
As a programmer, I'll accept liability for bugs in the code... the day I get the same protection that a professional engineer gets: if I say I need X for the program to be properly designed/written/tested, any manager or executive or marketer who says otherwise can be thrown in jail. No mere job protection, no civil remedies, jail time for anyone who tries to overrule me, same as would happen to a manager who overruled the structural engineer's specification of the grades of concrete and steel to be used in a building.
Responsibility and authority go hand in hand. If they want to hand the the responsibility, they give me the authority to go with it. If, OTOH, they don't want to give me the authority, then they can shoulder the responsibility.
My thought is that this should be a slam-dunk. Re-frame it this way: suppose the machine were a lab technician who'd performed an analysis on forensic evidence (blood test or something). Would it be legally acceptable for the state to say the defense had no right to put the technician up on the stand and question him about the procedures that were followed doing the test, that defense simply had to accept without question the technician's "Trust me, these results are right."? If defense has a right to cross-examine the technician, why should they have any less right to cross-examine the machine that's doing the same job?
Yes, I know you wouldn't pick apart a machine exactly the same way you'd question a lab tech. But the principle's the same: in both cases you want to know not just what the results were but what the tech/machine did, how they did it, and where they may have made a mistake, contaminated the evidence, failed to calibrate the equipment before testing or otherwise done something that changed or could have changed the results.
Seems to me that was what the judge in the first case held, and the judge here should rule the same way for the same reasons.
Because, if you read the article, it's not about people selling to other people. The licenses being comtemplated are for third parties selling to people on behalf of other people.
Example 1: you put your stuff up for sale on eBay yourself. Someone buys it. Neither of you needs a license.
Example 2: you don't know eBay well, so you hire Mr. X to put your stuff up for sale. Someone buys it from him. He collects the money and gives it to you. You don't need a license. The buyer doesn't need a license. Mr X would need a license.
The license and bond would, at least, act as some sort of insurance that Mr. X isn't going to sell your stuff, grab the money and disappear without leaving you any recourse. You could recover from his bond, and he'll have a hard time getting licensed and bonded again with the violation on his record, so it's in his interest not to do this.
Well, if the EU controls the roots, they could redirect the.com domain to servers they control rather than the ones run by NetSol. That'd let them take control over any TLD they wanted.
Thing is, the US and ICANN don't control the root servers. NetSol publishes the root hints file and the root zonefiles, but the servers themselves are mostly run by private entities. If those entities say "Sorry, we're not downloading your new root hints file and zonefile.", there's not a lot the US, ICANN or the EU could do about it. And as long as the majority of the world's still using the old hints file, those servers will remain authoritative no matter what kind of control or authority anyone else claims to have.
The problem is, what you propose wouldn't have even stopped the case that started this whole blow-up. In that case, the store didn't sell a minor the game, they sold it to his mother. She gave the game to the kid and let him play it. And what's even worse, the Illinois law that was passed in direct response to the incident specifically exempts a parent buying the game for their kid from prosecution under the law.
First, Mozilla-based browsers and the pop-up blocker and "don't load images from this site" controls.
Second, I control my own DNS server. It's authoritative for the zones I make it authoritative for, and queries the rest of DNS for the rest. DoubleClick a problem? Not after I associate all of DoubleClick's domains with a wildcard zonefile that resolves any hostname in those domains to one of my machines that, on ports 80 and 443, runs an HTTP server that returns "404 Not Found" for all queries.
Third, I control my own firewall. If you code ads using IP addresses and you're bothersome enough, I add a firewall rule redirecting all of your netblocks to the server I mentioned above. It's been a while since I've had to do this, though, DNS redirection seems to cover almost all current problems.
They interfere with my browser, causing it to malfunction in some way. It may crash, it may eat up memory and/or CPU cycles, in the end it simply malfs when presented with the ad.
The ad interferes with the page I'm trying to look at. This is a cardinal sin. I went to the page to see the page. An ad considering itself more important than the page it's on is the height of arrogance and I'm not inclined to put up with it. And as it turns out, I don't have to.
It interferes with my system in some way, eg. opening additional windows (esp. full-screen ones that cover up everything else on my desktop), moving windows from where I put them or resizing them to sizes I didn't set them to.
The ad attempts to do something anti-social, eg. downloading executable code. Sorry, not happening, and anyone who does it doesn't get a second chance.
The ad is from someone with an established history of abusing information, eg. DoubleClick. I don't give proven problems even a first chance. I learn from other people's mistakes, thank you very much.
If advertisers don't like this, well, personal problems are down the hall, third door on the left.
Bob may owe his increased business to Alice, but he doesn't owe her anything for her advertising. In the same way, the RIAA may have created a demand for 50 Cent but the people selling 50 Cent's music owe nothing to the RIAA aside from the royalties on the actual copies sold (and licensing fees for using his trademarks in ways not covered by fair use of those trademarks). If they make money selling soda and candy in the store to all the people who came in to buy 50 Cent's CDs, the RIAA has no claim on it.
Or, more likely, that the rest of the world realized instead (and much earlier) the benefits of a solution where everything works together well without needing to all use the same technology or be a single monolithic end-to-end solution.
To me, it doesn't matter whether SMTP is authenticated or not. I'm not trusting e-mail claiming anything, no matter what. If I really think the e-mail might be legit, instead of clicking on the link it provides I open up my browser and use my bookmark to that site instead. The assumption here is that if, for example, Paypal has a problem with my account, there will be something about it in my inbox on Paypal or a notice on my account page or something. If an e-mail says I need to verify my Citibank account by filling in a form, and I can't find a hint of anything like that on my account pages on Citibank's site (accessed from my bookmark, not through anything the e-mail provided), then no matter how authentic the e-mail looks it's actually bogus.
One of the problems with all the "We need authenticated SMTP!" proposals is that they're the equivalent of requiring authenticated snail-mail. USPS and SMTP are both transports. They have nothing to do with the identity of the entity sending the mail. No sane person would trust a bill for a large amount of money that arrived through the Postal Service just because it claimed to be from a store they did business with, the first thing they'd do is call the store and ask what's up. Same for e-mail: I'm not trusting an e-mail just because it says it's from someone, I'm going to contact that someone and see what's up.
You miss his point. What he's suggesting is a system that blocks those transactions even if the phisher has all that information.
Let's take electronic checks as an example. Currently, all I need to have to "write" an electronic check on your account is your account number. The bank'll assume the check's authorized unless you tell them otherwise (and why would you, since you don't have a clue this is happening until after the fact?). But suppose the bank made a simple change to the system, and assumed that electronic checks were not authorized unless you came to a branch in person and authorized it? Or at least authorized that specific entity to submit certain electronic checks (eg. only once and for not more than a certain amount)? Now it doesn't matter what I know, the bank's not going to let the transaction go through until you take some action to allow it. Or I forge your driver's license and take the risk of showing up at a branch of your bank impersonating you with my face now captured on video, and security guards between me and the doors if the teller twigs fast enough.
Another way is to start authenticating the bank to the customer, as well as authenticating the customer to the bank. SSL already has the ability to do this, all that's needed is some way in the browser UI to control the set of valid certificates used to verify the SSL session, eg. if I want to talk to Citibank I select "Citibank" from a pull-down menu and now my browser will only accept servers if they present an SSL certificate from a list I've associated with "Citibank" on my end. Now it doesn't matter how good a fake the phisher's e-mail or web site is, if they don't have the real private certificate my browser will just pop up a "Server does not belong to $BANK." error.
Re:Mass Spoofing (think fake japenese airfields WW
on
RIAA Sues a Child
·
· Score: 1
Don't just put a message like that in it, put your own original, copyrighted content in it and make sure your title is legitimate (ie. has enough relation to the material in the file to be a reasonable title on it's own merits). Then when the RIAA comes after you not only do you get to countersue for harrassment, you get to nail them for trying to misappropriate your copyright. Get a few people doing this together and you could probably make it even more painful for them by showing they're engaging in a pattern of behavior to do this on a large scale.
True, but I find it telling that she made her argument after the appeals court said thusly: "if appellees prove that an individual defect exists in all original MS-DOS 6.0 software, it is not necessary for the purchasers to actually suffer a loss of data as a result of a defect for them to suffer damage... They have received less than they bargained for when they acquired the product.". She's arguing directly counter to the appeals court. That's not cricket. It may be fine for a corporate lawyer, but I don't think that's appropriate in a Supreme Court Justice.
No, no memory leak, it just did a lot of object creation and destruction, which meant a lot of garbage to be cleaned up when the GC finally triggered. We thought it might be a leak, but heap analysis showed nothing was allocated after GC that shouldn't have been. A typical GC pass would free up about 1gig of memory, which was about right for the amount of object creation that'd been done. The behavior's the big strength of garbage-collected systems, and their big weakness (depending on how your program works).
All well and good. But suppose that car B, with all it's other advantages, is limited to a top speed of 45mph and can't go onto the freeways while car A has no problem with freeways. Most of your customers will want to go places where the fastest way there involves taking a freeway. As a taxi driver, which do you choose? For me it'd be easy: car B isn't an option because it doesn't meet minimum requirements, so car A's the only choice I have.
I ran into this situation when having to choose between Java and C++ for a program. The absolute requirement was consistent high performance (on the order of 500 transactions/second). It would've been easier to write this program in Java, frankly, and it'd've been theoretically able to meet the performance criteria. But. Yes, there's always a but. In this case it was the garbage collection. At random unpredictable and uncontrollable intervals the whole program would stop dead while the JVM did garbage collection. We tried multiple JVMs, we tried every option we could think of, we called in the vendors and had their techs try their hand at the problem. No joy. In C++ we had to manage memory ourselves and take care to avoid leaks, but at least we could at the same time slice deallocation up so it was a steady small overhead we could manage and account for in the performance budget.
Things like parameter order I consider to be not particularly critical: they're often required because of the particular transport involved, but the fact they exist isn't really crucial to what's happening. RPC vs. SOAP would be an example: SOAP attaches names to parameters so physical ordering is irrelevant, RPC doesn't so it has to use order, but that minor bookkeeping difference isn't really critical.
As far as monitoring and control, yes they're well on their way to becoming reality. That's because they were reality some, oh, 20-odd years ago.
Note that I'm not saying SOA is bad. It's good, for the same reason that structured programming is good. It's just nothing new or innovative, it's just another buzzword for a good modular architecture with clean interfaces and the ability to do remote procedure calls when appropriate. And it's going to have all of the same problems we've always had with similar architectures. The big one is defining the services to be provided. Creating a general-purpose service that's useful to a lot of things (a prerequisite to reusing the service elsewhere) takes time and care. Management usually says "Why is this taking so long? We need it now, stop wasting time trying to do all those things we don't care about.". End result is you end up with the same problem you get with regular object libraries: functions that, while in the library, don't actually do what your new program needs done and so can't be reused. I don't see SOA doing anything about that problem, so I don't see SOA succeeding where it's predecessors have languished.
I think the main problem is I've seen too much. After about the 4th or 5th time I hear another generation of new people expounding the same great idea, absolutely certain that it's new and never been tried, I tend to shrug and let reality deliver the reality check. I think I hit the "Whatever." stage about when Web applications were new and going to change the world and had nothing whatsoever in common with a system where the server uploaded a form definition to the browser, which could then let the user fill in the form fields, perform basic error checking and transmit the completed form back to the server. Because no Web application could possibly be similar to an IBM mainframe and a 3270-series workstation, you see.
I learned C++ and object-oriented programming when cfront was the implementation of choice for it. I also picked up "Design Patterns" 10 years ago when it first came out, and not a lot in it was new to me (although it was nice to have it all in one place and nicely laid-out). Ditto "Antipatterns", which I found equally useful.
Of course, when I was just learning C++, I also opined that it'd be a great language... in 10 years or so when they'd finally shaken it down and figured out how to use it right. I'd submit that my prediction was not inaccurate.
You're confusing a language binding of an API with the API itself. Java's merely one language you can bind an API to. SOAP is merely one way of encoding the call's arguments and return and transporting them over the network (it does the combined job of XDR and RPC in SunRPC). SOA is, I'm afraid, another way of saying "We'll break our software into components, then have anything that needs something done call the function in the component that does that.". It's fancied-up, but it boils down to what's been taught as good design/architecture practice for the last 30 years. I've been through about 4 iterations of this so far, I don't see this one being significantly different.
The big one is simple: "There's no such thing as reusable code, only code that has been reused.". It's very difficult to design code to be reused and get it right until after you've actually tried to reuse that code somewhere else and found all the problems. All code makes assumptions about how it's going to be used, and you usually don't realize which ones are true showstoppers until you go to use that code in a different way and get smacked in the face by them.
The rest of the problems with SOA are the same ones that've been around ever since someone throught up remote procedure calls. If you aren't familiar with RPC and XDR, what makes you think you won't make the same mistakes and face the same problems this time around?
The public doesn't have to back iTMS's stand. All that's needed is for Warner's offerings to not be so compelling compared to all the other labels to convince buyers to put out effort to set up an account somewhere other than iTMS and go through the convolutions needed to move WMA onto the iPod (I doubt Warner would sell their stuff as plain, unprotected MP3s, and Apple obviously wouldn't license their own DRM to Warner to set up competition). Given the state of CD and other music sales, I frankly don't think Warner's music's compelling enough to get people to put forth that kind of effort.
Well, look at it this way: the iPod-owning public wants to buy from iTMS, and they've got every label except Warner to choose from there. Is Warner's stuff really so compelling that they'll go to the effort of looking elsewhere just to get it? On-line distribution's the only channel that's actually showing improving sales, and iTMS is the 600lb gorilla in that area.
Were I Jobs or Apple, I'd pull a preemptive strike. Announce "Since Warner Records doesn't feel the agreement with iTMS is fair, we've decided to resolve the problem. All Warner titles have been removed from iTMS and Warner Records has been released from the agreement. They're now free to market their music through a service whose pricing is more in line with their desired price points.". Then sit back and watch Warner scream as their sales plummet.
Slashdot Mirror
I think they need evidence that a crime has been committed or is in the process of being committed, and that the person they want to track is involved in that crime. That last part especially is one they seem to want to skip.
My suspicion: Calc is holding a parsed XML document tree for the spreadsheet in memory, while Excel reduces it to an internal structure and recreates the XML when saving. Holding the document tree makes for more memory usage, but it allows for preserving of unknown XML without mangling it. Parsing to an internal structure is more efficient, but anything not recognized will be lost when saving.
NB: I don't think Calc works on the parsed XML, it probably has an internal representation to actually work on which is then tied back into the XML document so the XML can be updated to reflect the changes in the data.
I left a job earlier this year. Money wasn't the main reason I left, there were several more important issues that led me to even considering an offer in the first place, but by taking a job elsewhere I got a better than 20% raise. The iteration before that my salary stayed about the same but I got myself moved to a much better area of the country. The iteration before that I got out of a literally dead-end area and got a 30% raise in the process.
I think we're just going through an adjustment. For much of the 20th century you got raises by staying with one company a long time. As people got used to stability companies started to adjust by offering smaller and smaller raises, counting on unwillingness to risk the instability of a job hunt to keep workers from leaving. Workers have to adjust by accepting that raises now will come by shifting jobs, either to a radically different position within the company or more likely to a different company altogether. If you recognize that, you can get an advantage by looking for your next job while still employed. That's the playing field the companies seem to want, so the only real question is are you going to look for the most advantageous strategy for yourself or not?
Of course, in a couple of decades when workers have come to consider job-hopping the status quo, companies will begin to offer large raises and other benefits to try and keep employees around long-term and cut turnover costs. Or maybe they'll find some other strategy. The critical thing isn't what'll happen, but to be able to spot the trend early and follow it instead of lagging it.
As a programmer, I'll accept liability for bugs in the code... the day I get the same protection that a professional engineer gets: if I say I need X for the program to be properly designed/written/tested, any manager or executive or marketer who says otherwise can be thrown in jail. No mere job protection, no civil remedies, jail time for anyone who tries to overrule me, same as would happen to a manager who overruled the structural engineer's specification of the grades of concrete and steel to be used in a building.
Responsibility and authority go hand in hand. If they want to hand the the responsibility, they give me the authority to go with it. If, OTOH, they don't want to give me the authority, then they can shoulder the responsibility.
My thought is that this should be a slam-dunk. Re-frame it this way: suppose the machine were a lab technician who'd performed an analysis on forensic evidence (blood test or something). Would it be legally acceptable for the state to say the defense had no right to put the technician up on the stand and question him about the procedures that were followed doing the test, that defense simply had to accept without question the technician's "Trust me, these results are right."? If defense has a right to cross-examine the technician, why should they have any less right to cross-examine the machine that's doing the same job?
Yes, I know you wouldn't pick apart a machine exactly the same way you'd question a lab tech. But the principle's the same: in both cases you want to know not just what the results were but what the tech/machine did, how they did it, and where they may have made a mistake, contaminated the evidence, failed to calibrate the equipment before testing or otherwise done something that changed or could have changed the results.
Seems to me that was what the judge in the first case held, and the judge here should rule the same way for the same reasons.
Because, if you read the article, it's not about people selling to other people. The licenses being comtemplated are for third parties selling to people on behalf of other people.
Example 1: you put your stuff up for sale on eBay yourself. Someone buys it. Neither of you needs a license.
Example 2: you don't know eBay well, so you hire Mr. X to put your stuff up for sale. Someone buys it from him. He collects the money and gives it to you. You don't need a license. The buyer doesn't need a license. Mr X would need a license.
The license and bond would, at least, act as some sort of insurance that Mr. X isn't going to sell your stuff, grab the money and disappear without leaving you any recourse. You could recover from his bond, and he'll have a hard time getting licensed and bonded again with the violation on his record, so it's in his interest not to do this.
Well, if the EU controls the roots, they could redirect the .com domain to servers they control rather than the ones run by NetSol. That'd let them take control over any TLD they wanted.
Thing is, the US and ICANN don't control the root servers. NetSol publishes the root hints file and the root zonefiles, but the servers themselves are mostly run by private entities. If those entities say "Sorry, we're not downloading your new root hints file and zonefile.", there's not a lot the US, ICANN or the EU could do about it. And as long as the majority of the world's still using the old hints file, those servers will remain authoritative no matter what kind of control or authority anyone else claims to have.
The problem is, what you propose wouldn't have even stopped the case that started this whole blow-up. In that case, the store didn't sell a minor the game, they sold it to his mother. She gave the game to the kid and let him play it. And what's even worse, the Illinois law that was passed in direct response to the incident specifically exempts a parent buying the game for their kid from prosecution under the law.
Oh, and as for how I block ads? A couple of ways.
First, Mozilla-based browsers and the pop-up blocker and "don't load images from this site" controls.
Second, I control my own DNS server. It's authoritative for the zones I make it authoritative for, and queries the rest of DNS for the rest. DoubleClick a problem? Not after I associate all of DoubleClick's domains with a wildcard zonefile that resolves any hostname in those domains to one of my machines that, on ports 80 and 443, runs an HTTP server that returns "404 Not Found" for all queries.
Third, I control my own firewall. If you code ads using IP addresses and you're bothersome enough, I add a firewall rule redirecting all of your netblocks to the server I mentioned above. It's been a while since I've had to do this, though, DNS redirection seems to cover almost all current problems.
I block them for a number of reasons:
- They interfere with my browser, causing it to malfunction in some way. It may crash, it may eat up memory and/or CPU cycles, in the end it simply malfs when presented with the ad.
- The ad interferes with the page I'm trying to look at. This is a cardinal sin. I went to the page to see the page. An ad considering itself more important than the page it's on is the height of arrogance and I'm not inclined to put up with it. And as it turns out, I don't have to.
- It interferes with my system in some way, eg. opening additional windows (esp. full-screen ones that cover up everything else on my desktop), moving windows from where I put them or resizing them to sizes I didn't set them to.
- The ad attempts to do something anti-social, eg. downloading executable code. Sorry, not happening, and anyone who does it doesn't get a second chance.
- The ad is from someone with an established history of abusing information, eg. DoubleClick. I don't give proven problems even a first chance. I learn from other people's mistakes, thank you very much.
If advertisers don't like this, well, personal problems are down the hall, third door on the left.Bob may owe his increased business to Alice, but he doesn't owe her anything for her advertising. In the same way, the RIAA may have created a demand for 50 Cent but the people selling 50 Cent's music owe nothing to the RIAA aside from the royalties on the actual copies sold (and licensing fees for using his trademarks in ways not covered by fair use of those trademarks). If they make money selling soda and candy in the store to all the people who came in to buy 50 Cent's CDs, the RIAA has no claim on it.
Or, more likely, that the rest of the world realized instead (and much earlier) the benefits of a solution where everything works together well without needing to all use the same technology or be a single monolithic end-to-end solution.
To me, it doesn't matter whether SMTP is authenticated or not. I'm not trusting e-mail claiming anything, no matter what. If I really think the e-mail might be legit, instead of clicking on the link it provides I open up my browser and use my bookmark to that site instead. The assumption here is that if, for example, Paypal has a problem with my account, there will be something about it in my inbox on Paypal or a notice on my account page or something. If an e-mail says I need to verify my Citibank account by filling in a form, and I can't find a hint of anything like that on my account pages on Citibank's site (accessed from my bookmark, not through anything the e-mail provided), then no matter how authentic the e-mail looks it's actually bogus.
One of the problems with all the "We need authenticated SMTP!" proposals is that they're the equivalent of requiring authenticated snail-mail. USPS and SMTP are both transports. They have nothing to do with the identity of the entity sending the mail. No sane person would trust a bill for a large amount of money that arrived through the Postal Service just because it claimed to be from a store they did business with, the first thing they'd do is call the store and ask what's up. Same for e-mail: I'm not trusting an e-mail just because it says it's from someone, I'm going to contact that someone and see what's up.
You miss his point. What he's suggesting is a system that blocks those transactions even if the phisher has all that information.
Let's take electronic checks as an example. Currently, all I need to have to "write" an electronic check on your account is your account number. The bank'll assume the check's authorized unless you tell them otherwise (and why would you, since you don't have a clue this is happening until after the fact?). But suppose the bank made a simple change to the system, and assumed that electronic checks were not authorized unless you came to a branch in person and authorized it? Or at least authorized that specific entity to submit certain electronic checks (eg. only once and for not more than a certain amount)? Now it doesn't matter what I know, the bank's not going to let the transaction go through until you take some action to allow it. Or I forge your driver's license and take the risk of showing up at a branch of your bank impersonating you with my face now captured on video, and security guards between me and the doors if the teller twigs fast enough.
Another way is to start authenticating the bank to the customer, as well as authenticating the customer to the bank. SSL already has the ability to do this, all that's needed is some way in the browser UI to control the set of valid certificates used to verify the SSL session, eg. if I want to talk to Citibank I select "Citibank" from a pull-down menu and now my browser will only accept servers if they present an SSL certificate from a list I've associated with "Citibank" on my end. Now it doesn't matter how good a fake the phisher's e-mail or web site is, if they don't have the real private certificate my browser will just pop up a "Server does not belong to $BANK." error.
Don't just put a message like that in it, put your own original, copyrighted content in it and make sure your title is legitimate (ie. has enough relation to the material in the file to be a reasonable title on it's own merits). Then when the RIAA comes after you not only do you get to countersue for harrassment, you get to nail them for trying to misappropriate your copyright. Get a few people doing this together and you could probably make it even more painful for them by showing they're engaging in a pattern of behavior to do this on a large scale.
True, but I find it telling that she made her argument after the appeals court said thusly: "if appellees prove that an individual defect exists in all original MS-DOS 6.0 software, it is not necessary for the purchasers to actually suffer a loss of data as a result of a defect for them to suffer damage... They have received less than they bargained for when they acquired the product.". She's arguing directly counter to the appeals court. That's not cricket. It may be fine for a corporate lawyer, but I don't think that's appropriate in a Supreme Court Justice.
No, no memory leak, it just did a lot of object creation and destruction, which meant a lot of garbage to be cleaned up when the GC finally triggered. We thought it might be a leak, but heap analysis showed nothing was allocated after GC that shouldn't have been. A typical GC pass would free up about 1gig of memory, which was about right for the amount of object creation that'd been done. The behavior's the big strength of garbage-collected systems, and their big weakness (depending on how your program works).
All well and good. But suppose that car B, with all it's other advantages, is limited to a top speed of 45mph and can't go onto the freeways while car A has no problem with freeways. Most of your customers will want to go places where the fastest way there involves taking a freeway. As a taxi driver, which do you choose? For me it'd be easy: car B isn't an option because it doesn't meet minimum requirements, so car A's the only choice I have.
I ran into this situation when having to choose between Java and C++ for a program. The absolute requirement was consistent high performance (on the order of 500 transactions/second). It would've been easier to write this program in Java, frankly, and it'd've been theoretically able to meet the performance criteria. But. Yes, there's always a but. In this case it was the garbage collection. At random unpredictable and uncontrollable intervals the whole program would stop dead while the JVM did garbage collection. We tried multiple JVMs, we tried every option we could think of, we called in the vendors and had their techs try their hand at the problem. No joy. In C++ we had to manage memory ourselves and take care to avoid leaks, but at least we could at the same time slice deallocation up so it was a steady small overhead we could manage and account for in the performance budget.
Things like parameter order I consider to be not particularly critical: they're often required because of the particular transport involved, but the fact they exist isn't really crucial to what's happening. RPC vs. SOAP would be an example: SOAP attaches names to parameters so physical ordering is irrelevant, RPC doesn't so it has to use order, but that minor bookkeeping difference isn't really critical.
As far as monitoring and control, yes they're well on their way to becoming reality. That's because they were reality some, oh, 20-odd years ago.
Note that I'm not saying SOA is bad. It's good, for the same reason that structured programming is good. It's just nothing new or innovative, it's just another buzzword for a good modular architecture with clean interfaces and the ability to do remote procedure calls when appropriate. And it's going to have all of the same problems we've always had with similar architectures. The big one is defining the services to be provided. Creating a general-purpose service that's useful to a lot of things (a prerequisite to reusing the service elsewhere) takes time and care. Management usually says "Why is this taking so long? We need it now, stop wasting time trying to do all those things we don't care about.". End result is you end up with the same problem you get with regular object libraries: functions that, while in the library, don't actually do what your new program needs done and so can't be reused. I don't see SOA doing anything about that problem, so I don't see SOA succeeding where it's predecessors have languished.
I think the main problem is I've seen too much. After about the 4th or 5th time I hear another generation of new people expounding the same great idea, absolutely certain that it's new and never been tried, I tend to shrug and let reality deliver the reality check. I think I hit the "Whatever." stage about when Web applications were new and going to change the world and had nothing whatsoever in common with a system where the server uploaded a form definition to the browser, which could then let the user fill in the form fields, perform basic error checking and transmit the completed form back to the server. Because no Web application could possibly be similar to an IBM mainframe and a 3270-series workstation, you see.
I learned C++ and object-oriented programming when cfront was the implementation of choice for it. I also picked up "Design Patterns" 10 years ago when it first came out, and not a lot in it was new to me (although it was nice to have it all in one place and nicely laid-out). Ditto "Antipatterns", which I found equally useful.
Of course, when I was just learning C++, I also opined that it'd be a great language... in 10 years or so when they'd finally shaken it down and figured out how to use it right. I'd submit that my prediction was not inaccurate.
You're confusing a language binding of an API with the API itself. Java's merely one language you can bind an API to. SOAP is merely one way of encoding the call's arguments and return and transporting them over the network (it does the combined job of XDR and RPC in SunRPC). SOA is, I'm afraid, another way of saying "We'll break our software into components, then have anything that needs something done call the function in the component that does that.". It's fancied-up, but it boils down to what's been taught as good design/architecture practice for the last 30 years. I've been through about 4 iterations of this so far, I don't see this one being significantly different.
The big one is simple: "There's no such thing as reusable code, only code that has been reused.". It's very difficult to design code to be reused and get it right until after you've actually tried to reuse that code somewhere else and found all the problems. All code makes assumptions about how it's going to be used, and you usually don't realize which ones are true showstoppers until you go to use that code in a different way and get smacked in the face by them.
The rest of the problems with SOA are the same ones that've been around ever since someone throught up remote procedure calls. If you aren't familiar with RPC and XDR, what makes you think you won't make the same mistakes and face the same problems this time around?
The public doesn't have to back iTMS's stand. All that's needed is for Warner's offerings to not be so compelling compared to all the other labels to convince buyers to put out effort to set up an account somewhere other than iTMS and go through the convolutions needed to move WMA onto the iPod (I doubt Warner would sell their stuff as plain, unprotected MP3s, and Apple obviously wouldn't license their own DRM to Warner to set up competition). Given the state of CD and other music sales, I frankly don't think Warner's music's compelling enough to get people to put forth that kind of effort.
Well, look at it this way: the iPod-owning public wants to buy from iTMS, and they've got every label except Warner to choose from there. Is Warner's stuff really so compelling that they'll go to the effort of looking elsewhere just to get it? On-line distribution's the only channel that's actually showing improving sales, and iTMS is the 600lb gorilla in that area.
Were I Jobs or Apple, I'd pull a preemptive strike. Announce "Since Warner Records doesn't feel the agreement with iTMS is fair, we've decided to resolve the problem. All Warner titles have been removed from iTMS and Warner Records has been released from the agreement. They're now free to market their music through a service whose pricing is more in line with their desired price points.". Then sit back and watch Warner scream as their sales plummet.