I am not a lawyer. That said, here are a few comments on how I understand things and where I think they'd go. Your mileage may vary.
I always chuckle at this sort of thing. I like to call this "The Reiser Defense". If you ever followed the Hans Reiser trial, you'll note that he had a fundamental misunderstanding of how law works (or even is supposed to work). As a developer, he saw laws as a program. He thought that he had the program set up so as not to be able to convict him.
As it happens, the Law is not a program or set of mechanical rules. The Law may *appear* to be that way, but that's mostly a side effect of one of its goals. The Law is intended to be predictable so as not to be perverse when applied to people. The theory goes that people can only be held accountable for breaking laws if they can reasonably have been expected to know that they would fall afoul of it.
As it happens, this is not a blank check. You have responsibilities not to be entirely ignorant of the law. You have responsibilities to cooperate with law enforcement and the Court. You do not get to interpret the law any more than is necessary to mount your defense. All of your interpretations are subject to validation and endorsement by the Court. So the process surrounding justice use the trappings of a program or set of mechanical rules, but that is largely a construct to allow you to cooperate with the Court in executing the upholding the intent of the Law.
In fact, it's why it's called Contempt of Court. You have rights under the Law. It's the Court's responsibility to uphold those rights for you. Criminals do not respect the Law. If you behave in such a way as to prevent the Law from being applied by the Court, you show contempt for the rule of law and you hurt your chances in being able to exercise your rights under it. This is a fairly obvious social contract, and that contract--not some expectation that the law function as some sort of autistic machine--is what fundamentally underlies Due Process.
The Fifth Amendment is a law like any other. It's intention is to ensure that the parties involved in justice maintain separated duties. The theory is that you and the prosecution make claims and the court evaluates those claims. If the Court were permitted to compel you to make certain claims, then it's no longer really evaluating them and the integrity of the system breaks down. That's the context that Fifth Amendment lives in and that's the context within which Courts will evaluate it. It is not a "technicality" that gets you out of cooperating with warrants. So, while the law cannot force you to say something is true or false against your will, it *can* compel your cooperation in unlocking the filing cabinet containing the evidence that implies the same thing. That's the difference, evidence is different from testimony.
There is a bit of a grey area around combinations / passwords. This is largely due to prosecutors abusing your unwillingness to give them unfettered access to something as being parleyed into some kind of claim of guilt. That's what the Fifth Amendment addresses--your lack of a statement cannot be construed as a claim of guilt. This started with a dissent from the Supreme Court that mentioned that giving up the combination to a lock amounted to testimony that you had access to what it protects. It's similar to a different case where the prosecution subpoenaed "all of the papers that apply to " and the 5th was upheld as saying evaluating which papers were submitted papers would be tantamount to asking for testimony that some of the stuff was illegal. That fine line between testimony and your duty to comply with the collection of evidence by authorities is something best discussed with a lawyer, because it is not a silver bullet.
I believe that your unconventional take on copyright law isn't likely to get you anywhere. You're effectively claiming that Copyright Law puts you in a 'guilty until proven innocent' which is, more precisely, claiming a violatio
Inherently illegal isn't really a thing. Maybe you mean immoral?
In any case, courts in the US have been just fine with authorizing the killing of schoolchildren. None of the involved parties fried for it. http://en.wikipedia.org/wiki/G...
<troll>Ah, Windows... the gift that keeps on giving.</troll>
Seriously, though... this is pretty ugly. It checks back every five minutes for each machine. You would think that Sony IT would notice that network traffic (or, say, the fact that all of their Windows desktops started listening on port 443). The moral of this story is run an IDS, scan your network, and pay attention to it all!:(
Python's newer abstract base classes allow you to make types that specify the presence of abstract methods and properties and you can use isinstance(thing, base_class) to achieve something similar (and thereby making handling types more familiar to foreigners)
With respect to Java and call stacks; Java has no easy way to dispatch to a function by name. You either need to make a class hierarchy so that you can use virtual call dispatch; or you need an if-tree (which is ugly but underappreciated). I've seen a few Java brains melt when I give them something like:
Of course, I could just make a base class for spells and grow a giant, sparse API; but the benefit of playing the default-implementation / function overriding game is suboptimal. At the end of the day, the class hierarchy is just a data structure to determine how different "types" of functions get dispatched. As it happens, it spreads things out in a way that makes them hard to visualize. It often forces me to shadow unrelated sections of other APIs that grow on the same base-class.
In short, it's a crappy data structure for the purpose and it makes a pain out of gathering the knowledge to know how that dispatch happens. Sure, the code is "type-correct", but that doesn't say very much about being logically correct. As it happens, type errors are easy errors--but figuring out how the class hierarchy isn't serving your logical needs is *not* an easy error.
Don't get me wrong, I'm not fundamentally opposed to a good type system. First-class functions in Haskell or the like could handle this with type-safety. However, our industry just isn't ready for all of the pipes, beards, and sweaters. So, given the choice between Python and Java, I pick the one that give me methods for dynamic dispatch that don't abuse an already incredibly limited inheritance mechanism. I'll take the language that allows extensible, generic function application instead of getting it as a side-effect of their implementation of an already stunted type-system.
To be fair, I know what "kill -1" is for and I've never used it on purpose. Of course, that's because "kill -1" comes from the school of "fixing" the symptoms of the problem without understanding what's actually causing it.
The statement was very carefully worded "'It's clear that Brendan cannot lead Mozilla in this setting." The thing is, CEOs can have their career end in a heartbeat. Bad quarter? Stupid mistake? Bam! No more jobs. They are trusted to execute; no more, no less. This compromised that. He very likely wanted to leave, not because he was coerced by any action or inaction of the company--just because staying would effectively end his career (i.e. he could win the battle but lose the war, as it were).
There are two issues here--staying at Mozilla and getting hired somewhere else. The latter would have only gotten worse the longer he stayed. The former, well, his job just got infinitely harder no matter how you slice it. The sooner he got out the spotlight, the better off he is (and Mozilla is).
Is it fair to him? No. However, fair is not in the CEOs vocabulary. It's very likely this was his decision so he could go on to salvage what he could of the rest of his life.
Interestingly, the article says that, at the request of law enforcement, they added CAPTCHA support. The article then goes on to say that this must be a deception because they used a plural, it "doesn't make sense", etc.
Actually, it makes a lot of sense. How is every IED detonated these days? Cell phone. Buy a cheap, anonymous phone, wire it up, and call it to detonate it. Wifi that wasn't resistant to automated signup would make this trivial. They could just sign up with an anonymous phone and pre-paid Visa. Then, when it's in the air, *BOOM*
It also makes a lot of sense that they don't want to talk about it. Don't want to give people ideas.
Most programming confusion I've had to combat in the workplace comes from a fundamental misunderstanding of the two most basic facts of your program:
1. Where is your program's state stored? (NOTE: 90% of the time it's "the call stack" and 90% of the time that's the wrong place to put it.) 2. Where in your code is execution happening?
Threaded program generating weirdness? It's probably because you can't answer those two questions. Distributed program a mess to debug? I bet your state is smeared all over the place. Is your code a pain to port to an evented architecture? Bet you modeled your state badly. Can't map some failure to a certain, detectable set of circumstances? I guarantee your answer starts there.
For me, the answer to understanding these problems was found in functional programming. The no-side-effects stuff causes you to make all of your state concrete and also deeply understand what the call-stack does for you (or, more often than not, *to* you). The cruel reality, though, is that applying this hard-won knowledge *doesn't* seem lie in functional programming (or, at least, not LISP, Schema, Haskell, and crew).
If you're an academic, start with Hoare's Communicating Sequential Processes (http://www.usingcsp.com/cspbook.pdf), then learn Erlang (or Go, with a heavy emphasis on GoRoutines). If you're less Ivory Tower, try to grok this blog entry (http://blog.incubaid.com/2012/03/28/the-game-of-distributed-systems-programming-which-level-are-you/), then learn Erlang (or Go, with a heavy emphasis on GoRoutines).
I'm quite the proponent of researching molten salt nuclear. It's got some nice properties in terms of failure modes, is inherently anti-proliferation (so I hear), and has some nice options in the way of the thorium fuel cycle (the Chinese seem to have a real interest in this one, unsurprisingly).
Interestingly, molten salt SOLAR is actually quite nice for addressing the chief problem with solar (notably, the whole "sun goes down thing"). See here:
A lot of companies aren't interested in full disk encryption and the like without key escrow. Basically, they don't want an employee to be able to lock them out without clearly displaying malicious intent (i.e. no "I forgot the password" defense).
This is entirely true. Apple is content to let the Nokia's of the world go out of business serving a market segment that pays less.
Is this socially irresponsible? Possibly. However, survival trumps social responsibility (in business as much as life). Apple almost died once, its success is effectively built on that core lesson.
Arguments about proprietary screws being a sign of corporate malcontent are as old as time. I, for one, don't see what's wrong about establishing a basic line of defense against casual intrusion. Having sat at the table with the lawyers and product guys, I recognize that no ulterior motive is necessary once the lawyers realize that an idiot with a screwdriver can dump a few ounces of lithium acid in his lap. They might actually request proprietary screws just to plausibly say that they tried to keep them out.
Said another way, this is like an ISP port-blocking the default telnet port. It doesn't stop people from hacking, but it does stop the dumbest and it makes it look like you tried.
Density. Most Apple machines are difficult to repair for the same reasons that Japanese cars are hard to repair. Once you hit a certain density, you just have to give up on making it easy to disassemble. To be fair to Apple, they just decided to go full out. If it's going to be hard to repair at the desired component density, embrace that fact and build it like it's not going to be repaired.
Now, recycling is another matter, but in terms of repairability, if you want a reparable Mac, get the desktops. They're perfectly easy to work on. If you want a mobile device, where weight, size, and battery-life are king--expect it to be hard to repair.
Others have addressed many reasons on which road should take. I'd like to chime in on some important factors on which road you can take. Specifically:
If you have written anything already, your boss may already own it.
This shocks people sometimes, but it's entirely true. If you wrote it on work time, with work equipment, or even over work bandwidth; (in the USA) it legally belongs to them under federal copyright law. As soon as you're being paid to do it, they have a claim. Interestingly, this is why you always here about companies refusing to pay for something to negotiate a lower price, then being all shocked that the author sold it to someone else (or just gave it away). This sword cuts both ways. As soon as someone can squint sideways and see some way you were compensated to produce this software, then that benefactor has a claim.
That said, even if you've done it clean-room, on your own time, and entirely with your own resources; can you afford to defend it? Owning it doesn't mean much if they can just ignore you. Have a lawyer friend that will help you keep your ownership clear and is willing to send scary lawyer letters. This also means you must be willing to lose your job. It further means that your boss must have enough assets that, should they fire you, it's worth suing them.
Most importantly, try to do a better job selling it. Very few bosses will turn down a good opportunity. Even bad ones, when convinced of the savings, will go for it. Don't assume it's their job to know this stuff. It's their job to hire and manage people who know this stuff--that's a two-way street. If you want an opportunity to write some serious software, understand that you need to give them an opportunity to identify talent that can do so. Until you've both helped each other take that step (and both benefited from it), there's no way anyone can benefit. They're taking a risk--so sell them on it.
You'll find that you can do amazing things when your boss trusts in your judgement and will give you freedom. A lot of times the difference between a job and a career is finding management that you can interface with. Being a successful programmer or architect is entirely a people skill--establish trust, find a good boss, and you can make good money writing code without the BS. Alas, that might mean leaving your current job.
Finally (in case I haven't made this obvious yet), don't get so attached to your job. Really. If you're this concerned about how "your" job is going to take advantage of (or fail to take advantage of) your skills, I humbly suggest that you should mistrust your attachment to it. Working is like dating in a disturbing number of ways. It doesn't matter how "great" the place is, and it doesn't matter how much they "deserve" your "help". Find a partner that will appreciate you, or you're just going to be in a dead-end relationship and you won't realize it until you're way out of your prime. There are other fish in the sea (even in this market), and you should keep getting what you need from this one until you can trade up. If you feel dirty doing it, that's great--just don't settle for less than you should.
Every one? Even the abbreviated list is pretty long.
Are you making a Hasty Generalization? Then have you committed the Fallacist's Fallacy. For added fun, explain how your use of a fallacy doesn't mean you're wrong--which kind of defeats your point.
Proofs must be constructive. Without a counter-example, this is just doubt. Proof (and consequently counter-proof) generates certainty. This is the mechanic of science.
Why couldn't the particle stay the same, but the whole universe oscillates around it?
I actually don't mean to be ironic here. Perhaps they're mathematically the same. IANAPP (I am not a particle physicist). Still, just because something appears to change doesn't mean that it wasn't the observer that changed, right?
Slashdot Mirror
I am not a lawyer. That said, here are a few comments on how I understand things and where I think they'd go. Your mileage may vary.
I always chuckle at this sort of thing. I like to call this "The Reiser Defense". If you ever followed the Hans Reiser trial, you'll note that he had a fundamental misunderstanding of how law works (or even is supposed to work). As a developer, he saw laws as a program. He thought that he had the program set up so as not to be able to convict him.
As it happens, the Law is not a program or set of mechanical rules. The Law may *appear* to be that way, but that's mostly a side effect of one of its goals. The Law is intended to be predictable so as not to be perverse when applied to people. The theory goes that people can only be held accountable for breaking laws if they can reasonably have been expected to know that they would fall afoul of it.
As it happens, this is not a blank check. You have responsibilities not to be entirely ignorant of the law. You have responsibilities to cooperate with law enforcement and the Court. You do not get to interpret the law any more than is necessary to mount your defense. All of your interpretations are subject to validation and endorsement by the Court. So the process surrounding justice use the trappings of a program or set of mechanical rules, but that is largely a construct to allow you to cooperate with the Court in executing the upholding the intent of the Law.
In fact, it's why it's called Contempt of Court. You have rights under the Law. It's the Court's responsibility to uphold those rights for you. Criminals do not respect the Law. If you behave in such a way as to prevent the Law from being applied by the Court, you show contempt for the rule of law and you hurt your chances in being able to exercise your rights under it. This is a fairly obvious social contract, and that contract--not some expectation that the law function as some sort of autistic machine--is what fundamentally underlies Due Process.
The Fifth Amendment is a law like any other. It's intention is to ensure that the parties involved in justice maintain separated duties. The theory is that you and the prosecution make claims and the court evaluates those claims. If the Court were permitted to compel you to make certain claims, then it's no longer really evaluating them and the integrity of the system breaks down. That's the context that Fifth Amendment lives in and that's the context within which Courts will evaluate it. It is not a "technicality" that gets you out of cooperating with warrants. So, while the law cannot force you to say something is true or false against your will, it *can* compel your cooperation in unlocking the filing cabinet containing the evidence that implies the same thing. That's the difference, evidence is different from testimony.
There is a bit of a grey area around combinations / passwords. This is largely due to prosecutors abusing your unwillingness to give them unfettered access to something as being parleyed into some kind of claim of guilt. That's what the Fifth Amendment addresses--your lack of a statement cannot be construed as a claim of guilt. This started with a dissent from the Supreme Court that mentioned that giving up the combination to a lock amounted to testimony that you had access to what it protects. It's similar to a different case where the prosecution subpoenaed "all of the papers that apply to " and the 5th was upheld as saying evaluating which papers were submitted papers would be tantamount to asking for testimony that some of the stuff was illegal. That fine line between testimony and your duty to comply with the collection of evidence by authorities is something best discussed with a lawyer, because it is not a silver bullet.
I believe that your unconventional take on copyright law isn't likely to get you anywhere. You're effectively claiming that Copyright Law puts you in a 'guilty until proven innocent' which is, more precisely, claiming a violatio
Did you just claim that the validity of an argument is dependent on the manners of the messenger?
That sounds like something an idiot would say...
Inherently illegal isn't really a thing. Maybe you mean immoral?
In any case, courts in the US have been just fine with authorizing the killing of schoolchildren. None of the involved parties fried for it. http://en.wikipedia.org/wiki/G...
<troll>Ah, Windows... the gift that keeps on giving.</troll>
Seriously, though... this is pretty ugly. It checks back every five minutes for each machine. You would think that Sony IT would notice that network traffic (or, say, the fact that all of their Windows desktops started listening on port 443). The moral of this story is run an IDS, scan your network, and pay attention to it all! :(
A few notes:
Python's newer abstract base classes allow you to make types that specify the presence of abstract methods and properties and you can use isinstance(thing, base_class) to achieve something similar (and thereby making handling types more familiar to foreigners)
With respect to Java and call stacks; Java has no easy way to dispatch to a function by name. You either need to make a class hierarchy so that you can use virtual call dispatch; or you need an if-tree (which is ugly but underappreciated). I've seen a few Java brains melt when I give them something like:
cast_spell[spell_type](spell_data, casting_context)
Of course, I could just make a base class for spells and grow a giant, sparse API; but the benefit of playing the default-implementation / function overriding game is suboptimal. At the end of the day, the class hierarchy is just a data structure to determine how different "types" of functions get dispatched. As it happens, it spreads things out in a way that makes them hard to visualize. It often forces me to shadow unrelated sections of other APIs that grow on the same base-class.
In short, it's a crappy data structure for the purpose and it makes a pain out of gathering the knowledge to know how that dispatch happens. Sure, the code is "type-correct", but that doesn't say very much about being logically correct. As it happens, type errors are easy errors--but figuring out how the class hierarchy isn't serving your logical needs is *not* an easy error.
Don't get me wrong, I'm not fundamentally opposed to a good type system. First-class functions in Haskell or the like could handle this with type-safety. However, our industry just isn't ready for all of the pipes, beards, and sweaters. So, given the choice between Python and Java, I pick the one that give me methods for dynamic dispatch that don't abuse an already incredibly limited inheritance mechanism. I'll take the language that allows extensible, generic function application instead of getting it as a side-effect of their implementation of an already stunted type-system.
To be fair, I know what "kill -1" is for and I've never used it on purpose. Of course, that's because "kill -1" comes from the school of "fixing" the symptoms of the problem without understanding what's actually causing it.
Doesn't work for anything that changes a kernel data-structure. Only code-path changes. As a sysadmin, do you spend the time to know the difference?
But are they constructing additional pylons?
So much this.
The statement was very carefully worded "'It's clear that Brendan cannot lead Mozilla in this setting." The thing is, CEOs can have their career end in a heartbeat. Bad quarter? Stupid mistake? Bam! No more jobs. They are trusted to execute; no more, no less. This compromised that. He very likely wanted to leave, not because he was coerced by any action or inaction of the company--just because staying would effectively end his career (i.e. he could win the battle but lose the war, as it were).
There are two issues here--staying at Mozilla and getting hired somewhere else. The latter would have only gotten worse the longer he stayed. The former, well, his job just got infinitely harder no matter how you slice it. The sooner he got out the spotlight, the better off he is (and Mozilla is).
Is it fair to him? No. However, fair is not in the CEOs vocabulary. It's very likely this was his decision so he could go on to salvage what he could of the rest of his life.
Interestingly, the article says that, at the request of law enforcement, they added CAPTCHA support. The article then goes on to say that this must be a deception because they used a plural, it "doesn't make sense", etc.
Actually, it makes a lot of sense. How is every IED detonated these days? Cell phone. Buy a cheap, anonymous phone, wire it up, and call it to detonate it. Wifi that wasn't resistant to automated signup would make this trivial. They could just sign up with an anonymous phone and pre-paid Visa. Then, when it's in the air, *BOOM*
It also makes a lot of sense that they don't want to talk about it. Don't want to give people ideas.
Most programming confusion I've had to combat in the workplace comes from a fundamental misunderstanding of the two most basic facts of your program:
1. Where is your program's state stored? (NOTE: 90% of the time it's "the call stack" and 90% of the time that's the wrong place to put it.)
2. Where in your code is execution happening?
Threaded program generating weirdness? It's probably because you can't answer those two questions. Distributed program a mess to debug? I bet your state is smeared all over the place. Is your code a pain to port to an evented architecture? Bet you modeled your state badly. Can't map some failure to a certain, detectable set of circumstances? I guarantee your answer starts there.
For me, the answer to understanding these problems was found in functional programming. The no-side-effects stuff causes you to make all of your state concrete and also deeply understand what the call-stack does for you (or, more often than not, *to* you). The cruel reality, though, is that applying this hard-won knowledge *doesn't* seem lie in functional programming (or, at least, not LISP, Schema, Haskell, and crew).
If you're an academic, start with Hoare's Communicating Sequential Processes (http://www.usingcsp.com/cspbook.pdf), then learn Erlang (or Go, with a heavy emphasis on GoRoutines). If you're less Ivory Tower, try to grok this blog entry (http://blog.incubaid.com/2012/03/28/the-game-of-distributed-systems-programming-which-level-are-you/), then learn Erlang (or Go, with a heavy emphasis on GoRoutines).
This is so Fallout that it hurts.
I'm quite the proponent of researching molten salt nuclear. It's got some nice properties in terms of failure modes, is inherently anti-proliferation (so I hear), and has some nice options in the way of the thorium fuel cycle (the Chinese seem to have a real interest in this one, unsurprisingly).
Interestingly, molten salt SOLAR is actually quite nice for addressing the chief problem with solar (notably, the whole "sun goes down thing"). See here:
http://news.cnet.com/8301-11128_3-57333789-54/molten-salt-keeps-solar-power-flowing/
Right. You also get logging of the commands executed which can be nice, or can itself be a security problem.
However, unless you carefully restrict the commands, you can do what I do: "sudo bash" (or, if you prefer, "sudo -i")
A lot of companies aren't interested in full disk encryption and the like without key escrow. Basically, they don't want an employee to be able to lock them out without clearly displaying malicious intent (i.e. no "I forgot the password" defense).
This is entirely true. Apple is content to let the Nokia's of the world go out of business serving a market segment that pays less.
Is this socially irresponsible? Possibly. However, survival trumps social responsibility (in business as much as life). Apple almost died once, its success is effectively built on that core lesson.
Arguments about proprietary screws being a sign of corporate malcontent are as old as time. I, for one, don't see what's wrong about establishing a basic line of defense against casual intrusion. Having sat at the table with the lawyers and product guys, I recognize that no ulterior motive is necessary once the lawyers realize that an idiot with a screwdriver can dump a few ounces of lithium acid in his lap. They might actually request proprietary screws just to plausibly say that they tried to keep them out.
Said another way, this is like an ISP port-blocking the default telnet port. It doesn't stop people from hacking, but it does stop the dumbest and it makes it look like you tried.
TL;DR Perverse incentives are perverse.
Density. Most Apple machines are difficult to repair for the same reasons that Japanese cars are hard to repair. Once you hit a certain density, you just have to give up on making it easy to disassemble. To be fair to Apple, they just decided to go full out. If it's going to be hard to repair at the desired component density, embrace that fact and build it like it's not going to be repaired.
Now, recycling is another matter, but in terms of repairability, if you want a reparable Mac, get the desktops. They're perfectly easy to work on. If you want a mobile device, where weight, size, and battery-life are king--expect it to be hard to repair.
Relevant: http://www.dhmo.org/msdsdhmo.html
Others have addressed many reasons on which road should take. I'd like to chime in on some important factors on which road you can take. Specifically:
If you have written anything already, your boss may already own it.
This shocks people sometimes, but it's entirely true. If you wrote it on work time, with work equipment, or even over work bandwidth; (in the USA) it legally belongs to them under federal copyright law. As soon as you're being paid to do it, they have a claim. Interestingly, this is why you always here about companies refusing to pay for something to negotiate a lower price, then being all shocked that the author sold it to someone else (or just gave it away). This sword cuts both ways. As soon as someone can squint sideways and see some way you were compensated to produce this software, then that benefactor has a claim.
That said, even if you've done it clean-room, on your own time, and entirely with your own resources; can you afford to defend it? Owning it doesn't mean much if they can just ignore you. Have a lawyer friend that will help you keep your ownership clear and is willing to send scary lawyer letters. This also means you must be willing to lose your job. It further means that your boss must have enough assets that, should they fire you, it's worth suing them.
Most importantly, try to do a better job selling it. Very few bosses will turn down a good opportunity. Even bad ones, when convinced of the savings, will go for it. Don't assume it's their job to know this stuff. It's their job to hire and manage people who know this stuff--that's a two-way street. If you want an opportunity to write some serious software, understand that you need to give them an opportunity to identify talent that can do so. Until you've both helped each other take that step (and both benefited from it), there's no way anyone can benefit. They're taking a risk--so sell them on it.
You'll find that you can do amazing things when your boss trusts in your judgement and will give you freedom. A lot of times the difference between a job and a career is finding management that you can interface with. Being a successful programmer or architect is entirely a people skill--establish trust, find a good boss, and you can make good money writing code without the BS. Alas, that might mean leaving your current job.
Finally (in case I haven't made this obvious yet), don't get so attached to your job. Really. If you're this concerned about how "your" job is going to take advantage of (or fail to take advantage of) your skills, I humbly suggest that you should mistrust your attachment to it. Working is like dating in a disturbing number of ways. It doesn't matter how "great" the place is, and it doesn't matter how much they "deserve" your "help". Find a partner that will appreciate you, or you're just going to be in a dead-end relationship and you won't realize it until you're way out of your prime. There are other fish in the sea (even in this market), and you should keep getting what you need from this one until you can trade up. If you feel dirty doing it, that's great--just don't settle for less than you should.
This is why I really like Minecraft. Fun stuff can slide in without concerns about it interfering with it being a "sport".
Every one? Even the abbreviated list is pretty long.
Are you making a Hasty Generalization? Then have you committed the Fallacist's Fallacy. For added fun, explain how your use of a fallacy doesn't mean you're wrong--which kind of defeats your point.
Proofs must be constructive. Without a counter-example, this is just doubt. Proof (and consequently counter-proof) generates certainty. This is the mechanic of science.
Why couldn't the particle stay the same, but the whole universe oscillates around it?
I actually don't mean to be ironic here. Perhaps they're mathematically the same. IANAPP (I am not a particle physicist). Still, just because something appears to change doesn't mean that it wasn't the observer that changed, right?
Paravirtualization makes this the same thing with Xen. The difference is that Xen is the OS and Linux is the app.
You may not like Xen as an OS, but it does have some very nice qualities that are hard to deliver on Linux alone.
Actually, we support JRuby, classic Ruby (a.k.a. MRI), and we're working awfully hard to get Rubinius out the door, too.