You don't want to go there. The law is the one that says someone installing software on your computer without your permission is illegal. In your zeal to stop the Storm botnet, do you want to make it legal for the Storm botnet runners to break into your computer and install their software? That's what you'll be doing.
Actually there are good times to use GOTO. Finite state machines, for instance. The code's much easier to read if you use GOTOs to handle the transitions, trying to do it using only "structured code" constructs results in an unintelligible mass of spaghetti. Error handling's another case, it's much easier to parse a single GOTO to the exit code than the mass of nested conditionals needed to correctly handle erroring out of multiple nested loops and conditionals without using GOTO.
The key is knowing when GOTO makes the code simpler to read. Note that more compact != simpler.
IMO it depends on whether you're paying and have a contract or not. If you're not paying (in cash or in some other form), then the host should be entitled to terminate without warning. They should be required to provide a way for you to back up your content, but if you haven't been using it they shouldn't be obliged to do anything. You get what you pay for.
If you are paying, then at least 30 days' warning should be required and the host should be obliged to provide some way for you to transfer your data off. If they're taking money, they don't get to simply disregard their customers. A caveat to that should be that if there's a written contract then the terms of that contract should apply. If the contract lets the host terminate with no warning and no opportunity for you to recover your data, and you were dumb enough to sign it, then you should suffer the consequences. If there wasn't a written, signed contract (eg. all there was was the host's standard ToS that you didn't have to explicitly sign), then minimum requirements should apply regardless.
Google wants product and/or feature ideas. So what? That's a long way from actual implemented products. I'm minded of a comment by a published author to one of those fans with an "I've got a story idea, if you'll write it we can split the money 50-50." request: "You have a story idea? So do I. They're easy, I come up with a couple dozen story ideas a day. Actually writing it, spending 8 hours a day for the next 6 months hunkered over a keyboard hammering it into a full story and then into a finished manuscript ready for publishing, that's the hard part. So you want me to do the hard 95% and give you half the results? What, do I look crazy?". Google's basically asking "What do you want to see?", and if some of the suggestions look good they're do the hard part of developing and implementing them. I don't see a problem there. I might have heartburn if they were asking for actual implementations they could use, but it doesn't sound like they are.
What would worry me here is NASA's history. The Apollo 1 fire. Challenger. Columbia. The common thread in all of them is NASA engineers saying "We have a problem, we need to stop and fix it.", and NASA management going "It's OK, we haven't had a problem yet.". So when I hear NASA engineers saying "This isn't going to work.", and NASA management going "Everything's going to work, we just need to fix a few little things.", I start wondering what reason I have to believe things aren't going to work out just like the last few times.
NASA engineers are really good at solving problems. NASA management is very bad at acknowledging they have a problem that the engineers need to solve.
Prior art would be Conquest and similar games: 2D space-war simulators with multiple players. Central server, each player ran a client that talked to the server, players could join or leave a game and the game would add or remove their units from the universe. Display was rather primitive seeing as it ran on ASCII-text terminals connected to the computer through serial ports, but it did all the basics. The only thing it didn't do was use a cluster of servers, and see KSR Teleflex for that. Clustering was well-known even way back then, and applying the well-known principles of clustering servers to create a cluster of servers for a game falls under the heading of an obvious combination if there ever was one.
Internet marketing brought us forum spam in the first place, I'm afraid.
For most forums it's not about getting the most users at any cost. It's about getting the most interested visitors without scaring an unacceptable fraction away, while at the same time keeping the number of spammers at a manageable level (which, given their proclivities, is pretty close to zero). And the simple fact is that, if it can be automated, spammers can and will automate it. And as long as it costs them little or no time or effort, they'll continue to flood the forum. Getting around filters can be automated.
I'm reminded of an exchange:
Merchant: I need some way to keep people from stealing my merchandise all the time!
Consultant: <looks over the racks of high-value jewelry sitting outside the store> Well, why don't you move your merchandise inside, instead of leaving it out along the sidewalk?
Merchant: I can't do that! People couldn't see my merchandise, and I might lose customers!
Consultant:... so why exactly did you hire me again?
The fastest way is probably to just slow down user registration. Permit anonymous posting, but make it moderated/screened by default (ie. not visible to other users until the forum owner flags it as OK). When a user goes to register (so they can get their posts visible immediately), do not send them the confirmation e-mail immediately. Batch your confirmations up and send them out twice a day at odd times (ie. not midnight and noon, something like 3:47am and 3:47 pm) (you could do it 4 times a day, but not much faster than that since the idea's to introduce a delay in the registration process). Make sure to tell the user on the registration screen what sort of time-frame they can expect their confirmation to arrive in. Ordinary users who plan on using the forum long-term won't be inconvenienced much by this. Spammers... won't tolerate the delay, they want to get their message in fast and get out. With their automated scripts they might not even notice things are failing. Also, don't include a direct confirmation link in the e-mail. Include a URL to a form and make the user copy-and-paste the confirmation number from the e-mail. That'll be trivial for humans, but not easy for an automated script to handle without human assistance.
None of that will stop a determined spammer, but most of them are more interested in volume than anything else and they won't bother spending time/effort on just one forum when they could hit 10 others instead.
I think it's useful to look at what the judge was saying. It sounds like he's saying there's a distinction in the law between making available with full intent that someone else take advantage of it, vs. making available unwittingly and by accident or by the action of someone else that you were unaware of or had no control over, and that the RIAA doesn't get to roll it all under just plain "making available" and ignore the distinction. The judge seems to be holding that the RIAA's "making available" argument isn't completely invalid but they need to show either intent or unreasonable carelessness on the part of the defendant, and without that mere "making available" isn't sufficient for what the RIAA's asking.
So if the judge is upheld on appeal, you'd be safe. If the RIAA wins without additional showings, you'd be guilty of infringing distribution.
I wouldn't use their portal at all. Doing so would involve entering my e-mail password into a page potentially hosted by someone other than the e-mail provider. I don't do that. Period, end of discussion. Not with any password, ever. That kind of thing is exactly what the phishers try to get you to do, and I don't need my passwords leaking out.
And if they tried to force it by prohibiting direct access to those e-mail sites, I'd send them a little letter with an agreement to fill out. An agreement stating that they take full responsibility for any disclosure of my password, including responsibility for all costs of any sort directly or indirectly related to the disclosure. If they refuse, the whole exchange goes to the regulators attached to a complaint about them requiring me to disclose my passwords to them without them taking responsibility for them.
The only way you can do this is if you centralize access: place the document only on a central server and only allow access to it by viewing it on that server. Then that server can log every access and where it came from. That means, BTW, that you can't make the document accessible via a Web server, since the user could just do "Save As..." and make a local copy. Ditto making it available from a file share. You'd need to set up remote access to the server (X11 and an SSH tunnel, for instance, or Windows Remote Desktop), lock down any sort of remote transfer (disallow SCP, disallow the remoted desktop from sending files to it's local desktop) and provide a viewing application that logged accesses.
The fundamental problem is that once you give a copy of a document to someone, you've got little control over what they do with it. It's the same problem we've always had with documents: if you give someone a physical document, you've precious little control over whether they slap it in a photocopier and run off a few copies of it to give to people they shouldn't. Approach the problem in the same way you'd approach the same problem with a physical document.
I guess it depends on your idea of trivial. It might take more than a day or two to write the software to do it, but it certainly is not difficult.
If it were so trivial, somebody would've done it by now. A successful algorithm's got so many commercial applications it's not even funny. FedEx and UPS, for instance, and in fact any shipping company would pay a pretty penny for an algorithm that'd spit out the most efficient loading pattern for any given load of packages. And your algorithm would have to be even more complicated, since it's not only got to figure out the most efficient packing but has to take into account the various ways you can change the sizes of the objects you're packing into the space.
As a programmer I love non-programmers who insist they know what's easy and what's not. It's fun to watch them squirm when they get put on the hook for actually doing it.
Then you get a different printing technology. I don't believe for a second that it can't be done cheaply. The printers in use today work the way they do because they satisfy the requirements. Change the requirements, and the designs will change with it.
To quote: "Fast, cheap, correct. Pick any two.". And it's true. What you're doing, though, is setting up requirements that essentially demand all three. You need a large number of copies. You need them extremely quickly. And you demand that each one be individualized enough that you have to treat this as a large number of single-copy jobs instead of a single large-number-of-copies job. The problem is that if you could solve this problem, your solution would be even more efficient at the job offset presses do. Newspapers aren't the only printers out there, and every magazine publisher, every comic publisher, every catalog publisher would kill for the solution you're wanting. Now, with all that incentive, why has nobody come up with something fitting what you want? Because when it comes down to transferring ink to paper, you're stuck with the physical limitations of ink (in all it's forms) and paper and the mechanics of transferring the former onto the latter. And that's where all the "solutions" run aground, because regardless of what the PHBs might like the physical world doesn't need to change to suit their desires and nobody's yet come up with a sufficient bribe to make it want to.
Not that the problem can't be solved, mind you. It just can't be solved in a printed medium. Take away the paper and ink and the solutions become trivial. But then you've transformed the entire newspaper into a Web site, with all it's content distributed electronically with no printing involved. And if the papers can't figure out how to make a Web site pay for itself, what makes you think they're going to be any more successful figuring out how to make a Web site pay for itself?
There's no manual labor currently. But that doesn't mean there's no work involved, or that it's not expensive. Automatic layout... isn't quite as automatic as all that, it's rather non-trivial to fit things properly onto a fixed-size page. Once it's done, you then need to create plates for each page. Even using modern polymer-coated sheet-metal plates etched under computer control, it takes an hour or so to get the plates ready for a given edition. So you're going to print one copy, then spend another hour preparing for the next person's copy? Right, you're now at being able to produce maybe 24 copies a day per press. You simply can't afford to buy enough printers. The idea works when you're talking about tens or hundreds of print jobs in a day, but it breaks down when you start talking about thousands or tens of thousands (which is what a newspaper would need).
And no, going to laser printers won't work. You don't need to etch plates, but you also get 1/10th the printing speed (an offset press runs at around 300 pages per minute, a fast laster printer 30 or less depending on page size). You have to use much more expensive paper (newsprint's too flimsy to feed through a laser printer's feed path, and it's surface is too coarse and porous for toner to adhere and fuse properly) and much more expensive ink (even the cheapest toner costs several times as much per page as the ink a newspaper users). You end up with vastly higher per-copy costs, and people simply aren't going to pay several times as much for your paper.
All over the place. At work I just finished cleaning up a thread-safety problem. We hold an identifier in a data member of an object, and we log that identifier as part of all messages to identify where the transaction came from. At the end of a transaction this programmer spawned off a new thread to log the final statistics and timings for the transaction the object was for, then destroyed the object and terminated the processing thread. I got tasked with figuring out why the identifier being logged for the statistics and timing messages were garbage.
And this isn't atypical. 50-75% of our applicants fail to even see that there's a problem in the above case.
There might be a market, but there's no business model. Newspaper printing presses aren't like your home inkjet printer. They're designed to print thousands of copies of the same thing. Even with electronic typesetting, it requires a fair amount of physical setup to be ready to print the first copy. They're cheap because they do all the pre-press work once and then spread the cost across all their copies. What you're suggesting is that they do the whole pre-press setup once for each copy of the paper they produce. They can't do that at a price you could afford to pay.
Now, the on-line version, that they can customize cheaply.
The first is that the hardware cost isn't the only cost involved. There's also the costs of running and maintaining that hardware. Many performance problems can't be solved by throwing just a single bigger machine at the problem, and every one of the multiple machines means more complexity in the system, another piece that can fail. And it introduces more interactions that can cause failures. An application may be perfectly stable using a single database server, but throw a cluster of 3 database servers into the mix and a problem with the load-balancing between the DB servers can create failures where none existed before. Those sorts of failures can't be addressed by throwing more hardware at the problem, they need code written to stabilize the software. And that sort of code requires the kind of programmer that you don't get cheap right out of school. So now you're spending money on hardware and you're still having to hire those pesky expensive programmers you were trying to avoid hiring. And your customers are looking at the failure rates and deciding that maybe they'd like to go with your competitor who's more expensive but at least delivers what he promises.
Second is that, even if the problem's one that can be solved just by adding more hardware, often inexperienced programmers produce code whose performance profile isn't linear, it's exponential. That is, doubling the load doesn't require twice the hardware to maintain performance, it requires an order of magnitude more hardware. It doesn't take long for the hardware spending to become completely unbearab le, and you'll again be caught having to spend tons of cash on enough hardware to limp along while spending tons of money on really expensive programmers to try and get the software to where it's performance curve is supportable and watching your customers bail to someone offering better than same-day service on transactions.
Go ask Google. They're the poster boy for throwing hardware at the problem. Ask them what it took on the programming-expertise side to create software that would let them simply throw hardware at the problem.
The first is already pretty much law. A union can't in general demand membership as a condition of employment, and as far as dues go Communications Workers of America v. Beck set the rule that a union can only demand of non-members that fraction of dues that go directly to collective-bargaining expenses when that non-member is covered by the resulting contract. They can't require non-members to pay any portion of the dues that don't go to paying for collective bargaining.
As for allowing employers to fire striking workers, no thank you. That completely guts the union, the employer can simply ignore the union and if they strike or slow down work or do anything else to exert their influence the employer can simply fire everybody. That's worse than not having a union at all.
But I'd like to point out that, to professionals, it's grotesquely offensive.
As a professional myself, it's not offensive at all. The IEEE and the ACM are professional organizations lots of computer professionals are member of. A union is just another professional organization. Now, I'd be offended at one that put time-in-grade above merit, but there's nothing in any law anywhere that says a union must give seniority precedence over everything else. Only the contracts the union negotiates say that, and the union can negotiate contracts that say otherwise just as easily. And the members get to vote on what contract offers the union will make, and vote on the officers who run the union. It's just a matter of the union members standing up to their own union and saying "No. You will do things our way, or we'll replace you with someone who will.". It's just dealing with another set of PHBs, not like we don't have plenty of experience with that except that this time it's us who hold the big "We can fire you." club.
Or you would contribute to the codebase, and Sun would pick up your contribution and put it into their non-BSD-licensed code. And if they made a nice improvement to your code, they could keep that improvement in their version and not license it under BSD terms. Leaving Sun to benefit from your work without you being able to benefit from Sun's (even though Sun's wouldn't have been possible without yours).
Or one of Sun's competitors could do the same thing with Sun's work: base their product on it with a few additions of their own, and leave Sun out in the cold as far as those nice additions go. Which is bad for Sun.
No, the GPL doesn't force you to send your changes to the upstream. It does, however, force you to let the upstream get your changes and incorporate them if they wish to (they simply become a downstream recipient of your additions in that case).
And for a company like Sun, they don't want to share the maintenance burden. They'd want to insure that no competitor can take their code and release it with a new feature without Sun being able to grab that feature and add it to their own code. If Sun used the MIT/BSD license, a competitor could release the code under a restricted license that'd prevent Sun doing that.
Touch-screens will work on mobile and hand-held devices. They're fine for anything where you don't need to use the UI for very long. But if you're going to be moving the cursor and selecting things for 8 hours a day (as is normal for business computer use), you run up against basic anatomy and physiology: it hurts to hold your arm out in front of you (where your computer screen is) for long periods. No amount of UI design will change that. And I just don't see tablet computers replacing standard monitor-and-keyboard setups for work that involves a lot of typing (as most business use does). The only way you can resolve the issue is to move the pointing device from out in front of the user to down beside the keyboard so they don't have to hold their arm up in front of them anymore. But you need to keep the display out in front, because that's where the user's head naturally looks. Hmm, that's looking at lot more like a standard screen plus mouse/trackball/touchpad than a touchscreen, isn't it?
NB: a relative of gorilla-arm is why a lot of people prefer trackballs to mice and touchpads. Less arm movement, less muscle strain.
One of the keys to a successful open-source project is to take the improvements being made in forks and bring them back into the main project. One of the reasons forks are created is that users have a need that's not being met by the project. If you bring their solutions back into the mainline project, the fork will tend to die because it's no longer needed.
This is, BTW, one of the reasons to use a GPL-like license. If you do, you're guaranteed that you can bring improvements from forks back into your mainline codebase. If you go with a license that allows you to create a fork with things that aren't available to others, it simultaneously allows others to create forks that aren't available to you. Then you end up in Sun's situation with no way to resolve it except by creating the same improvements yourself. And there's more of your competitors than there are of you, which means they will win this particular race to create improvements. If you go with a license that forces improvements to be available to you but not anybody else, many people who might have created an improvement you could use will simply not contribute to your project. It's a perception issue: GPL-like terms lead contributors to think in terms of their contributions helping everybody and you just happen to be one of that "everybody", while "owner gets everything, everybody else gets what the owner gives them" terms tend to lead contributors to think you want them to work solely for your benefit without you giving them anything in return. That turns a lot of people off.
I've traditionally left my machines running, to avoid thermal stress from power-cycling and mechanical wear on parts from spinning up from a dead stop. I've found the big savings comes from two things:
Power down the display when not in use. CRTs were the single biggest power-hog on a computer, and putting them into a low-power standby mode (trickle current to keep the circuitry warm for restart) was an instant 40% power savings. LCDs use less power, but since they don't have coils and beam guns that need to be kept warm I can turn them off pretty much completely.
Use an OS that knows how to properly idle the processor and chipset. Done right, you can cut 75% of the mainboard's power consumption without actually powering anything down.
If I need more power savings, I might spin down the hard drives. But modern drives don't use that much power just to keep the platters spinning, most of their power consumption's driving the heads. Simply retracting the heads and not moving them lowers the drive's power consumption by a fairly big percentage, and that'll happen automatically when the system isn't accessing the disk. None of this requires any fancy sleep or hibernate or suspend magic.
I have noticed one thing, though. My Linux systems go idle fairly cleanly. Nothing's happening, minimal CPU time gets used (mainly the regular cron process waking up to check whether there's anything to run, then going back to sleep) and the hard drive stays completely idle. Windows, OTOH, keeps pinging the hard drive every 5 seconds or so even when completely idle. It's not much, just enough to make the HDD light flicker, but I don't see that with Linux. It makes me wonder how much of the "You need to put your system to sleep!" hype is simply because Windows doesn't know how to idle properly?
Yes, Esther, both anonymity and abortion are unfortunate things.
In a perfect world where people never made mistakes in judgement, where contraception never failed, where women were never raped, where sudden medical complications didn't arise out of nowhere, where events beyond your control never turned your life upside-down without warning, we'd never had a need for abortion.
And in a perfect world where people with power never abused that power to take revenge against those who made their misdeeds public, where bullies and petty tyrants never attempted to "punish" those who didn't bow to them, where fraudsters never attempted to masquerade as others, where criminals never attempted to use information for illicit gain, and where small-minded people never made life miserable for those who weren't exactly like them, we'd never have a need for anonymity either.
You already get 55% XP potions as veteran-reward items. Nothing new there. The only new thing is the achievement-XP potion. That's 10% or 25% for 4 hours, 50% for 2 hours. But it only boosts AXP you earn. Unlike regular XP, relatively few things give AXP. Quests, discovery locations and named-mob kills are the big things. And how many quests can you complete in 2 hours? How many nameds can you realistically find and kill? And you can't farm them, you get AXP for any given quest, discovery or named kill once and once only. So that potion isn't adding a lot in the end. Plus, with TSO they've already added automatic experience boosts for adventuring and crafting based on the number of max-level characters you have (up to 50%), and a bonus to achievement XP for mentoring down and completing lower-level content at an appropriate level. You can get more of a boost for free than the best buyable potions will give you. Overall, I'm filing the effects of those potions as minimal.
I'll start to have heartburn when they start selling access to content via microtransactions. When you have to shell out real dollars (beyond buying an expansion when it comes out) to be able to get your epic weapon, or to get access to an instance or raid zone, things like that. That'll only fly if it's done from the very start of a game, so people know going in what the ground rules will be. And I'm betting that approach won't be popular. Not in the sense that people will complain about it, people will always scream. In the sense that a lot of people will look at the whole framework and go "I don't want the headaches. I don't want to have to worry about my friends wanting to do an instance and I can't because I have to buy access and I won't have the money for it until payday.". It's an American thing: we're willing to pay $40/month for unlimited phone service when we normally only make $20-25 worth of billable calls because we'd rather spend the bit extra for the certainty that we're not going to get dinged with an exceptionally high bill some month.
Slashdot Mirror
You don't want to go there. The law is the one that says someone installing software on your computer without your permission is illegal. In your zeal to stop the Storm botnet, do you want to make it legal for the Storm botnet runners to break into your computer and install their software? That's what you'll be doing.
Actually there are good times to use GOTO. Finite state machines, for instance. The code's much easier to read if you use GOTOs to handle the transitions, trying to do it using only "structured code" constructs results in an unintelligible mass of spaghetti. Error handling's another case, it's much easier to parse a single GOTO to the exit code than the mass of nested conditionals needed to correctly handle erroring out of multiple nested loops and conditionals without using GOTO.
The key is knowing when GOTO makes the code simpler to read. Note that more compact != simpler.
IMO it depends on whether you're paying and have a contract or not. If you're not paying (in cash or in some other form), then the host should be entitled to terminate without warning. They should be required to provide a way for you to back up your content, but if you haven't been using it they shouldn't be obliged to do anything. You get what you pay for.
If you are paying, then at least 30 days' warning should be required and the host should be obliged to provide some way for you to transfer your data off. If they're taking money, they don't get to simply disregard their customers. A caveat to that should be that if there's a written contract then the terms of that contract should apply. If the contract lets the host terminate with no warning and no opportunity for you to recover your data, and you were dumb enough to sign it, then you should suffer the consequences. If there wasn't a written, signed contract (eg. all there was was the host's standard ToS that you didn't have to explicitly sign), then minimum requirements should apply regardless.
Google wants product and/or feature ideas. So what? That's a long way from actual implemented products. I'm minded of a comment by a published author to one of those fans with an "I've got a story idea, if you'll write it we can split the money 50-50." request: "You have a story idea? So do I. They're easy, I come up with a couple dozen story ideas a day. Actually writing it, spending 8 hours a day for the next 6 months hunkered over a keyboard hammering it into a full story and then into a finished manuscript ready for publishing, that's the hard part. So you want me to do the hard 95% and give you half the results? What, do I look crazy?". Google's basically asking "What do you want to see?", and if some of the suggestions look good they're do the hard part of developing and implementing them. I don't see a problem there. I might have heartburn if they were asking for actual implementations they could use, but it doesn't sound like they are.
What would worry me here is NASA's history. The Apollo 1 fire. Challenger. Columbia. The common thread in all of them is NASA engineers saying "We have a problem, we need to stop and fix it.", and NASA management going "It's OK, we haven't had a problem yet.". So when I hear NASA engineers saying "This isn't going to work.", and NASA management going "Everything's going to work, we just need to fix a few little things.", I start wondering what reason I have to believe things aren't going to work out just like the last few times.
NASA engineers are really good at solving problems. NASA management is very bad at acknowledging they have a problem that the engineers need to solve.
Prior art would be Conquest and similar games: 2D space-war simulators with multiple players. Central server, each player ran a client that talked to the server, players could join or leave a game and the game would add or remove their units from the universe. Display was rather primitive seeing as it ran on ASCII-text terminals connected to the computer through serial ports, but it did all the basics. The only thing it didn't do was use a cluster of servers, and see KSR Teleflex for that. Clustering was well-known even way back then, and applying the well-known principles of clustering servers to create a cluster of servers for a game falls under the heading of an obvious combination if there ever was one.
Internet marketing brought us forum spam in the first place, I'm afraid.
For most forums it's not about getting the most users at any cost. It's about getting the most interested visitors without scaring an unacceptable fraction away, while at the same time keeping the number of spammers at a manageable level (which, given their proclivities, is pretty close to zero). And the simple fact is that, if it can be automated, spammers can and will automate it. And as long as it costs them little or no time or effort, they'll continue to flood the forum. Getting around filters can be automated.
I'm reminded of an exchange: ... so why exactly did you hire me again?
Merchant: I need some way to keep people from stealing my merchandise all the time!
Consultant: <looks over the racks of high-value jewelry sitting outside the store> Well, why don't you move your merchandise inside, instead of leaving it out along the sidewalk?
Merchant: I can't do that! People couldn't see my merchandise, and I might lose customers!
Consultant:
The fastest way is probably to just slow down user registration. Permit anonymous posting, but make it moderated/screened by default (ie. not visible to other users until the forum owner flags it as OK). When a user goes to register (so they can get their posts visible immediately), do not send them the confirmation e-mail immediately. Batch your confirmations up and send them out twice a day at odd times (ie. not midnight and noon, something like 3:47am and 3:47 pm) (you could do it 4 times a day, but not much faster than that since the idea's to introduce a delay in the registration process). Make sure to tell the user on the registration screen what sort of time-frame they can expect their confirmation to arrive in. Ordinary users who plan on using the forum long-term won't be inconvenienced much by this. Spammers... won't tolerate the delay, they want to get their message in fast and get out. With their automated scripts they might not even notice things are failing. Also, don't include a direct confirmation link in the e-mail. Include a URL to a form and make the user copy-and-paste the confirmation number from the e-mail. That'll be trivial for humans, but not easy for an automated script to handle without human assistance.
None of that will stop a determined spammer, but most of them are more interested in volume than anything else and they won't bother spending time/effort on just one forum when they could hit 10 others instead.
I think it's useful to look at what the judge was saying. It sounds like he's saying there's a distinction in the law between making available with full intent that someone else take advantage of it, vs. making available unwittingly and by accident or by the action of someone else that you were unaware of or had no control over, and that the RIAA doesn't get to roll it all under just plain "making available" and ignore the distinction. The judge seems to be holding that the RIAA's "making available" argument isn't completely invalid but they need to show either intent or unreasonable carelessness on the part of the defendant, and without that mere "making available" isn't sufficient for what the RIAA's asking.
So if the judge is upheld on appeal, you'd be safe. If the RIAA wins without additional showings, you'd be guilty of infringing distribution.
I wouldn't use their portal at all. Doing so would involve entering my e-mail password into a page potentially hosted by someone other than the e-mail provider. I don't do that. Period, end of discussion. Not with any password, ever. That kind of thing is exactly what the phishers try to get you to do, and I don't need my passwords leaking out.
And if they tried to force it by prohibiting direct access to those e-mail sites, I'd send them a little letter with an agreement to fill out. An agreement stating that they take full responsibility for any disclosure of my password, including responsibility for all costs of any sort directly or indirectly related to the disclosure. If they refuse, the whole exchange goes to the regulators attached to a complaint about them requiring me to disclose my passwords to them without them taking responsibility for them.
The only way you can do this is if you centralize access: place the document only on a central server and only allow access to it by viewing it on that server. Then that server can log every access and where it came from. That means, BTW, that you can't make the document accessible via a Web server, since the user could just do "Save As..." and make a local copy. Ditto making it available from a file share. You'd need to set up remote access to the server (X11 and an SSH tunnel, for instance, or Windows Remote Desktop), lock down any sort of remote transfer (disallow SCP, disallow the remoted desktop from sending files to it's local desktop) and provide a viewing application that logged accesses.
The fundamental problem is that once you give a copy of a document to someone, you've got little control over what they do with it. It's the same problem we've always had with documents: if you give someone a physical document, you've precious little control over whether they slap it in a photocopier and run off a few copies of it to give to people they shouldn't. Approach the problem in the same way you'd approach the same problem with a physical document.
I guess it depends on your idea of trivial. It might take more than a day or two to write the software to do it, but it certainly is not difficult.
If it were so trivial, somebody would've done it by now. A successful algorithm's got so many commercial applications it's not even funny. FedEx and UPS, for instance, and in fact any shipping company would pay a pretty penny for an algorithm that'd spit out the most efficient loading pattern for any given load of packages. And your algorithm would have to be even more complicated, since it's not only got to figure out the most efficient packing but has to take into account the various ways you can change the sizes of the objects you're packing into the space.
As a programmer I love non-programmers who insist they know what's easy and what's not. It's fun to watch them squirm when they get put on the hook for actually doing it.
Then you get a different printing technology. I don't believe for a second that it can't be done cheaply. The printers in use today work the way they do because they satisfy the requirements. Change the requirements, and the designs will change with it.
To quote: "Fast, cheap, correct. Pick any two.". And it's true. What you're doing, though, is setting up requirements that essentially demand all three. You need a large number of copies. You need them extremely quickly. And you demand that each one be individualized enough that you have to treat this as a large number of single-copy jobs instead of a single large-number-of-copies job. The problem is that if you could solve this problem, your solution would be even more efficient at the job offset presses do. Newspapers aren't the only printers out there, and every magazine publisher, every comic publisher, every catalog publisher would kill for the solution you're wanting. Now, with all that incentive, why has nobody come up with something fitting what you want? Because when it comes down to transferring ink to paper, you're stuck with the physical limitations of ink (in all it's forms) and paper and the mechanics of transferring the former onto the latter. And that's where all the "solutions" run aground, because regardless of what the PHBs might like the physical world doesn't need to change to suit their desires and nobody's yet come up with a sufficient bribe to make it want to.
Not that the problem can't be solved, mind you. It just can't be solved in a printed medium. Take away the paper and ink and the solutions become trivial. But then you've transformed the entire newspaper into a Web site, with all it's content distributed electronically with no printing involved. And if the papers can't figure out how to make a Web site pay for itself, what makes you think they're going to be any more successful figuring out how to make a Web site pay for itself?
There's no manual labor currently. But that doesn't mean there's no work involved, or that it's not expensive. Automatic layout... isn't quite as automatic as all that, it's rather non-trivial to fit things properly onto a fixed-size page. Once it's done, you then need to create plates for each page. Even using modern polymer-coated sheet-metal plates etched under computer control, it takes an hour or so to get the plates ready for a given edition. So you're going to print one copy, then spend another hour preparing for the next person's copy? Right, you're now at being able to produce maybe 24 copies a day per press. You simply can't afford to buy enough printers. The idea works when you're talking about tens or hundreds of print jobs in a day, but it breaks down when you start talking about thousands or tens of thousands (which is what a newspaper would need).
And no, going to laser printers won't work. You don't need to etch plates, but you also get 1/10th the printing speed (an offset press runs at around 300 pages per minute, a fast laster printer 30 or less depending on page size). You have to use much more expensive paper (newsprint's too flimsy to feed through a laser printer's feed path, and it's surface is too coarse and porous for toner to adhere and fuse properly) and much more expensive ink (even the cheapest toner costs several times as much per page as the ink a newspaper users). You end up with vastly higher per-copy costs, and people simply aren't going to pay several times as much for your paper.
All over the place. At work I just finished cleaning up a thread-safety problem. We hold an identifier in a data member of an object, and we log that identifier as part of all messages to identify where the transaction came from. At the end of a transaction this programmer spawned off a new thread to log the final statistics and timings for the transaction the object was for, then destroyed the object and terminated the processing thread. I got tasked with figuring out why the identifier being logged for the statistics and timing messages were garbage.
And this isn't atypical. 50-75% of our applicants fail to even see that there's a problem in the above case.
There might be a market, but there's no business model. Newspaper printing presses aren't like your home inkjet printer. They're designed to print thousands of copies of the same thing. Even with electronic typesetting, it requires a fair amount of physical setup to be ready to print the first copy. They're cheap because they do all the pre-press work once and then spread the cost across all their copies. What you're suggesting is that they do the whole pre-press setup once for each copy of the paper they produce. They can't do that at a price you could afford to pay.
Now, the on-line version, that they can customize cheaply.
The first is that the hardware cost isn't the only cost involved. There's also the costs of running and maintaining that hardware. Many performance problems can't be solved by throwing just a single bigger machine at the problem, and every one of the multiple machines means more complexity in the system, another piece that can fail. And it introduces more interactions that can cause failures. An application may be perfectly stable using a single database server, but throw a cluster of 3 database servers into the mix and a problem with the load-balancing between the DB servers can create failures where none existed before. Those sorts of failures can't be addressed by throwing more hardware at the problem, they need code written to stabilize the software. And that sort of code requires the kind of programmer that you don't get cheap right out of school. So now you're spending money on hardware and you're still having to hire those pesky expensive programmers you were trying to avoid hiring. And your customers are looking at the failure rates and deciding that maybe they'd like to go with your competitor who's more expensive but at least delivers what he promises.
Second is that, even if the problem's one that can be solved just by adding more hardware, often inexperienced programmers produce code whose performance profile isn't linear, it's exponential. That is, doubling the load doesn't require twice the hardware to maintain performance, it requires an order of magnitude more hardware. It doesn't take long for the hardware spending to become completely unbearab le, and you'll again be caught having to spend tons of cash on enough hardware to limp along while spending tons of money on really expensive programmers to try and get the software to where it's performance curve is supportable and watching your customers bail to someone offering better than same-day service on transactions.
Go ask Google. They're the poster boy for throwing hardware at the problem. Ask them what it took on the programming-expertise side to create software that would let them simply throw hardware at the problem.
The first is already pretty much law. A union can't in general demand membership as a condition of employment, and as far as dues go Communications Workers of America v. Beck set the rule that a union can only demand of non-members that fraction of dues that go directly to collective-bargaining expenses when that non-member is covered by the resulting contract. They can't require non-members to pay any portion of the dues that don't go to paying for collective bargaining.
As for allowing employers to fire striking workers, no thank you. That completely guts the union, the employer can simply ignore the union and if they strike or slow down work or do anything else to exert their influence the employer can simply fire everybody. That's worse than not having a union at all.
But I'd like to point out that, to professionals, it's grotesquely offensive.
As a professional myself, it's not offensive at all. The IEEE and the ACM are professional organizations lots of computer professionals are member of. A union is just another professional organization. Now, I'd be offended at one that put time-in-grade above merit, but there's nothing in any law anywhere that says a union must give seniority precedence over everything else. Only the contracts the union negotiates say that, and the union can negotiate contracts that say otherwise just as easily. And the members get to vote on what contract offers the union will make, and vote on the officers who run the union. It's just a matter of the union members standing up to their own union and saying "No. You will do things our way, or we'll replace you with someone who will.". It's just dealing with another set of PHBs, not like we don't have plenty of experience with that except that this time it's us who hold the big "We can fire you." club.
Or you would contribute to the codebase, and Sun would pick up your contribution and put it into their non-BSD-licensed code. And if they made a nice improvement to your code, they could keep that improvement in their version and not license it under BSD terms. Leaving Sun to benefit from your work without you being able to benefit from Sun's (even though Sun's wouldn't have been possible without yours).
Or one of Sun's competitors could do the same thing with Sun's work: base their product on it with a few additions of their own, and leave Sun out in the cold as far as those nice additions go. Which is bad for Sun.
No, the GPL doesn't force you to send your changes to the upstream. It does, however, force you to let the upstream get your changes and incorporate them if they wish to (they simply become a downstream recipient of your additions in that case).
And for a company like Sun, they don't want to share the maintenance burden. They'd want to insure that no competitor can take their code and release it with a new feature without Sun being able to grab that feature and add it to their own code. If Sun used the MIT/BSD license, a competitor could release the code under a restricted license that'd prevent Sun doing that.
Just two words: gorilla arm.
Touch-screens will work on mobile and hand-held devices. They're fine for anything where you don't need to use the UI for very long. But if you're going to be moving the cursor and selecting things for 8 hours a day (as is normal for business computer use), you run up against basic anatomy and physiology: it hurts to hold your arm out in front of you (where your computer screen is) for long periods. No amount of UI design will change that. And I just don't see tablet computers replacing standard monitor-and-keyboard setups for work that involves a lot of typing (as most business use does). The only way you can resolve the issue is to move the pointing device from out in front of the user to down beside the keyboard so they don't have to hold their arm up in front of them anymore. But you need to keep the display out in front, because that's where the user's head naturally looks. Hmm, that's looking at lot more like a standard screen plus mouse/trackball/touchpad than a touchscreen, isn't it?
NB: a relative of gorilla-arm is why a lot of people prefer trackballs to mice and touchpads. Less arm movement, less muscle strain.
One of the keys to a successful open-source project is to take the improvements being made in forks and bring them back into the main project. One of the reasons forks are created is that users have a need that's not being met by the project. If you bring their solutions back into the mainline project, the fork will tend to die because it's no longer needed.
This is, BTW, one of the reasons to use a GPL-like license. If you do, you're guaranteed that you can bring improvements from forks back into your mainline codebase. If you go with a license that allows you to create a fork with things that aren't available to others, it simultaneously allows others to create forks that aren't available to you. Then you end up in Sun's situation with no way to resolve it except by creating the same improvements yourself. And there's more of your competitors than there are of you, which means they will win this particular race to create improvements. If you go with a license that forces improvements to be available to you but not anybody else, many people who might have created an improvement you could use will simply not contribute to your project. It's a perception issue: GPL-like terms lead contributors to think in terms of their contributions helping everybody and you just happen to be one of that "everybody", while "owner gets everything, everybody else gets what the owner gives them" terms tend to lead contributors to think you want them to work solely for your benefit without you giving them anything in return. That turns a lot of people off.
I've traditionally left my machines running, to avoid thermal stress from power-cycling and mechanical wear on parts from spinning up from a dead stop. I've found the big savings comes from two things:
If I need more power savings, I might spin down the hard drives. But modern drives don't use that much power just to keep the platters spinning, most of their power consumption's driving the heads. Simply retracting the heads and not moving them lowers the drive's power consumption by a fairly big percentage, and that'll happen automatically when the system isn't accessing the disk. None of this requires any fancy sleep or hibernate or suspend magic.
I have noticed one thing, though. My Linux systems go idle fairly cleanly. Nothing's happening, minimal CPU time gets used (mainly the regular cron process waking up to check whether there's anything to run, then going back to sleep) and the hard drive stays completely idle. Windows, OTOH, keeps pinging the hard drive every 5 seconds or so even when completely idle. It's not much, just enough to make the HDD light flicker, but I don't see that with Linux. It makes me wonder how much of the "You need to put your system to sleep!" hype is simply because Windows doesn't know how to idle properly?
Yes, Esther, both anonymity and abortion are unfortunate things.
In a perfect world where people never made mistakes in judgement, where contraception never failed, where women were never raped, where sudden medical complications didn't arise out of nowhere, where events beyond your control never turned your life upside-down without warning, we'd never had a need for abortion.
And in a perfect world where people with power never abused that power to take revenge against those who made their misdeeds public, where bullies and petty tyrants never attempted to "punish" those who didn't bow to them, where fraudsters never attempted to masquerade as others, where criminals never attempted to use information for illicit gain, and where small-minded people never made life miserable for those who weren't exactly like them, we'd never have a need for anonymity either.
Pity this isn't a perfect world we live in.
You already get 55% XP potions as veteran-reward items. Nothing new there. The only new thing is the achievement-XP potion. That's 10% or 25% for 4 hours, 50% for 2 hours. But it only boosts AXP you earn. Unlike regular XP, relatively few things give AXP. Quests, discovery locations and named-mob kills are the big things. And how many quests can you complete in 2 hours? How many nameds can you realistically find and kill? And you can't farm them, you get AXP for any given quest, discovery or named kill once and once only. So that potion isn't adding a lot in the end. Plus, with TSO they've already added automatic experience boosts for adventuring and crafting based on the number of max-level characters you have (up to 50%), and a bonus to achievement XP for mentoring down and completing lower-level content at an appropriate level. You can get more of a boost for free than the best buyable potions will give you. Overall, I'm filing the effects of those potions as minimal.
I'll start to have heartburn when they start selling access to content via microtransactions. When you have to shell out real dollars (beyond buying an expansion when it comes out) to be able to get your epic weapon, or to get access to an instance or raid zone, things like that. That'll only fly if it's done from the very start of a game, so people know going in what the ground rules will be. And I'm betting that approach won't be popular. Not in the sense that people will complain about it, people will always scream. In the sense that a lot of people will look at the whole framework and go "I don't want the headaches. I don't want to have to worry about my friends wanting to do an instance and I can't because I have to buy access and I won't have the money for it until payday.". It's an American thing: we're willing to pay $40/month for unlimited phone service when we normally only make $20-25 worth of billable calls because we'd rather spend the bit extra for the certainty that we're not going to get dinged with an exceptionally high bill some month.