To keep your real name offline to the best of your ability. I see no reason for people online to know my real name, or tie it to my internet activities. Maybe you should get better internet activities? I get job offers from mine, where there's value in all of my activities being tied together.
Should the students be allowed to install and run anything they want on school computers? Can you do that at YOUR job? Yes, both presently and at every job I have had during the 15 years since I started in the workforce, excepting a single 3-week consulting gig in 1996 where I used a common workstation and what I was supposed to do only required the use of a text editor and the pre-installed web browser.
This is, of course, subject to "no obvious abuse". My present contract says I can do whatever I want, with the only limitation that I should not do something that hurts or is likely to hurt the company.
Lucene is a full text indexer. It does NOT need MySQL full text indexing; it does full text indexing all by itself. This is a primary point.
If Wikipedia had used MyISAM (or MySQL hadn't tied full text indexing to their storage engines), Wikipedia could have used MySQL full text searches instead of Lucene. That is a completely different matter, though.
So, please, mod parent to oblivion. (And when do we get a "Wrong" moderation? It could be a warning to moderators to look before they mod things up again...)
If I've understood things correctly, that's the different of dismissing "with and without prejudice". If you dismiss without prejudice, you can bring the suit again later, while if you dismiss with prejudice, you admit that the case is moot and can't bring it again.
("The game" was supposed to be "The game industry", so my last post read a bit different than I meant.)
No, normally game advances are recoupable, in other words, you don't get any more royalties until the advance is paid down. However, my point was that you as a developer/artist do not need to pay back the advance if the game/record don't make enough money to give more royalties than the advance. Actually, you'd better be able to live off the advance, because due to various "Hollywood accounting" tricks it's fairly likely to be all the money you'll see...
...from the previous poster is absurd. It's not a good idea. The fact is a lot of artists would lose a lot of money, and we're not talking income here necessarily. Many of them may not be able to "pay off" their advances. Having worked in game. The standard for such advances are NON-REFUNDABLE advances. The music industry can't be so fucked these advances are refundable; it's the entire basis of that kind of publishing.
You are assuming that more than one app - using more than one language/framework - is going to touch the database.
Beep. You're not allowed to touch my database. My database is owned by the set of classes lying just above it. This is the ONLY allowed interface, because it allows me to keep my application code - like what you are writing in those stored procedures - in a more reasonable language.
So, there is no repetition. And for some of those apps I may even get the proper relational model, instead of SQL, because my personal little ORM implements it for me;)
You are assuming that the database is to be defined before the app, and that the way to access the database is through the ORM mapping. This assumption works against the way a lot of us work - for the way I personally work (and the ways most of the companies I've dealt with over the last 5 years works), each app mostly owns a database. If you want access to a "foreign" database, you use a web service.
The other kind of situation - the one you describe - has also happened, of course. However, in my experience, that's a much less common situation. Maybe a 10% situation. Of course, what's likely is that we work in different kinds of environments - I mostly work with fairly small or fairly young companies, or supplying new systems.
My point is just that there is a "good living" to be made for a web framework in that area. Enough so that Rails don't need to support the other kind of app to be useful and thrive. (Heck, even the web framework we use at work thrive, and that's maintained by just two people on a part time basis, and does much of the same as Rails. Plus compound keys. Knowing the entire codebase well is a grand plus:)
My contract prohibits me from engaging in the same business as my current employer for up to 5 years after termination.
So you can't use your expertise to make a living for 5 years? Or does you contract have your employer paying you severance for 5 years?
Norway (where I live) has an interesting variant of this: Non-competes are enforceable, but ONLY if the former employer pay you full salary (including benefit) for the non-compete period. I know of only one company that has actually done this in practice - it led to some friends of mine getting a year off with full pay. ("You say we get a year of vacation with pay if we resign and start working for XXX? Damn, that just was a good offer.")
True, but a robot ear can never be programmed to hear what a human ear hears. A robot can't really bring out the emotion in a song. (It could be very good at simulating emotion, though). What human ears hear differ depending on what sounds you grew up with (certain types of plasticity are believed to disappear at approx age 2). So, while a robot may have a disadvantage in not having a specific human ear (and the trained neural system connected to it), it can have the advantage of being able to simulate many of them, and thus know when what it specific to one ear or type of ear, and when it is general.
"Irreducible complexity" isn't possible to prove false; as a such, I don't see it as worthy of the name "hypothesis". It is a source for hypotheses - a number of which has been put forth, and (as you note) have been proven false.
I also find the entire concept somewhat specious, since it assumes that you can prove that something isn't possible to add to or delete from to get another function. This seems roughly impossible to prove even for a single case; it only can be disproven case by case, and even when it isn't disproven that doesn't really show anything beyond "nobody yet having found a way to disprove it for this particular case", not a demonstration that "this particular case cannot be disproven".
It is sometimes possible, depending on the exact way we use the symmetric cipher and the exact symmetric cipher.
Three examples:
First, a stream cipher. A stream cipher is a cipher that generate a pseudorandom stream of data, which you then XOR with your data stream. The most well-known stream ciphers are RC4 (used in e.g. SSL) and the one-time pad (having a bunch of true random data you XOR with your data, where the random stream is the same length as your data). The attack here is that the attacker can randomly flip bits in your data, at whatever offset he choose.
Second, a standard block cipher, employed in block-at-a-time mode (Electronic Codebook - ECB - Mode). Most standard symmetric ciphers are block ciphers - on encrypt, they take one block of plaintext (uncrypted data) and a key and produce an encrypted block (ciphertext); on decrypt, they take a block of ciphertext and a key and produce corresponding the plaintext block. In "block at a time mode" you just sequentially split the plaintext into blocks, encrypt each block with the key, and write it to the output. There are three weaknesses here: First, the attacker can replace blocks of your data with other blocks of your data, even if he can't know the content of the data. If the data is highly structured and he knows the structure, he may be able to do a targetted attack by replacing a block. Secondly, he may randomly trash a block. Again, problem with structured data. Thirdly, he may learn of the content of the data by learning which blocks are equal. This is a significant information leak, which can help with the two modification attacks above (and is very unfortunate in its own right). This brings us to the third large example, which is
Third example, a block cipher used in block chaining (CBC) mode. Here, each block of plaintext is XORed with the previous block of ciphertext before being encrypted. This is probably the most common way to use block ciphers, as they are no longer vulnerable to the information leak above. In CBC mode, a one bit corruption in a ciphertext block will trash the corresponding decrypted data block - and cause a controlled one-bit change in the next data block. Without integrity checking, this can be VERY unfortunate.
There are other block cipher modes available, with other properties, including some that are supposed to provide integrity. I am not really familiar with those, so I'll stop here. The point was just to show that you absolutely have to take integrity into considering; the symmetric crypto doesn't give it to you for free, at least not in many significant cases.
Key words "false witness" and "against your neighbour". It refers to telling of lies, but even more specifically against one's neighbour. This is an interpretation of the English translation. The original is not neighbor; it means something more like "other person", though with a sort of implication of a spirit of closeness (though including everybody). There isn't a good word in English, so "neighbor" is a reasonable translation - just don't try to make it "what the Bible says", because the Bible wasn't written in English, and the word doesn't restrict to the people living close to you.
It's about justice and truth. It does not mean one cannot have an opinion in the topic we are currently discussing. Nice try though.:-) The traditional Protestant and Catholic interpretation is that you should not misrepresent the truth. By forming an opinion before investigating the truth, you end up misrepresenting the truth. In this particular case, there are two valid opinions:
(A) The set of living species we have was created through evolution, and (B) somebody set things up to fool us into thinking the present species was created through evolution. Those are the only two that could be true, given the evidence. So, anybody going against that are, to my mind, misrepresenting the truth, generally (99%+) through ignorance, being good people.
If you believe in a Designer, I expect that is the Christian God. As a such, you should also believe in the ten commandments. These include the 7th, "Thou shalt not bear false witness."
By publicly stating an opinion you are bearing witness.
By the kind of witness you are bearing, you show that you have not carefully studied the evidence WRT evolution.
The 7th commandment is not "Thou shalt not bear false witness unless there's a spot of bother to find out what the truth is".
So: Be a good Christian. Delay your witness until you have carefully studied the evidence.
ID could be a hypothesis if it put forth a testable point. Alas, to date, it does to the best of my knowledge not put forth any testable points, nor is there any plan or direction for how it COULD put forth any testable points. There is no way it could be disproven. As a such, I find it hard to credit it as a hypothesis. It is a sources of hypotheses - most of which has so far been shot down - but calling it a hypothesis in itself is giving it too much credit. In my opinon.
Note, though, that posting code on a forum with no copyright notice does not put it in the public domain. But it may effectively do so, through estoppel.
Perhaps the code was posted by magical faries, but that doesn't mean shit. The OP didn't say where it came from, and the implication was that there was no explicit license associated with the code, otherwise why bother asking. That being the case, social norms don't mean shit when you go before a judge. Actually, they can give rise to Estoppel. The definition of estoppel (from Wikipedia):
Estoppel is a legal doctrine recognised both at common law and in equity in various forms. It is meant to complement the requirement of consideration in contract law. In general it protects a party who would suffer detriment if:
* The defendant has done or said something to induce an expectation
* The plaintiff relied (reasonably) on the expectation...
*...and would suffer detriment if that expectation were false. Perfectly reasonable for this case. Of course, this assumes that it was the original author that posted the code, not somebody else.
I haven't just studied one - I live in one (Norway). And I see much less of those hubris problems than in, for instance, the US, where just about everybody seems to be crazy religious, both from what statistics I see and what I saw by being there. Like, most people go to church and stuff? WEIRD. We don't do that. And our leaders end up humanist and nice, not anywhere near as power-crazy as it seems to be in the US.
Pride in a religion is nothing wrong unless you start killing people in its name. I mostly agree with your formulation, though I'll extend it a little bit (and I think you'll agree with it): Pride in a religion is OK as long as you don't hurt people due to it.
This do, though, increase the scope quite a bit, as it means people can't use religion as a basis for a kind of action that end up hurting people, even when the damage is non-intentional. With that constraint, I feel religion as OK, and a solace and inspiration for people (even though I am an atheist myself.)
That means your questions includes assumptions that makes them wrong. Please learn more about the issues, and you will get better questions. The process of educating you about these areas is longer than I can do in a single, simple post - I'll just say that there are a ton of information out there that will make you get better questions:) It is also very much fun to learn.
I personally find any other interpretation of quantum mechanics to be less counter-intuitive than the Copenhagen interpretation. I especially find the "attribute magic powers to special arrangements of matter" (the observer) aspect of the Copenhagen interpretation to be totally counter-intuitive.
Cramer's transactional interpretation, on the other hand, handles all of this elegantly, and the only change it does is assuming a kind of handshake particle running backwards in time at the speed of ligth. Given that we have no time at the speed of light (given relativity), this seems nicely intuitive.
Linux does not get contribution from non-free codebases. BSDs does. Compared to mindshare, the BSDs get more contributions overall.
You seem to be misreading more or less on purpose. And you also seem to be doing the standard GPL crosstalk that the GPL increase free software, which works under an assumption that companies do the same development on a free codebase regardsless of the license; they would do the development and release a proprietary product if it wasn't for the GPL, and with the GPL they do the same development and release it for everybody to use. Think carefully on this assumption - when you do, I'm sure you'll agree that it is wrong. And the GPL "causing more free software" is for the most part dependent on that assumption. (There are other, indirect ways that the GPL can cause development - for instance, it keeps the people that are paranoid of being "exploited" comfortable, which sometimes is a boon.)
Slashdot Mirror
Eivind.
This is, of course, subject to "no obvious abuse". My present contract says I can do whatever I want, with the only limitation that I should not do something that hurts or is likely to hurt the company.
Eivind.
If Wikipedia had used MyISAM (or MySQL hadn't tied full text indexing to their storage engines), Wikipedia could have used MySQL full text searches instead of Lucene. That is a completely different matter, though.
So, please, mod parent to oblivion. (And when do we get a "Wrong" moderation? It could be a warning to moderators to look before they mod things up again...)
Eivind.
Eivind.
No, normally game advances are recoupable, in other words, you don't get any more royalties until the advance is paid down. However, my point was that you as a developer/artist do not need to pay back the advance if the game/record don't make enough money to give more royalties than the advance. Actually, you'd better be able to live off the advance, because due to various "Hollywood accounting" tricks it's fairly likely to be all the money you'll see...
Eivind.
Eivind.
Beep. You're not allowed to touch my database. My database is owned by the set of classes lying just above it. This is the ONLY allowed interface, because it allows me to keep my application code - like what you are writing in those stored procedures - in a more reasonable language.
So, there is no repetition. And for some of those apps I may even get the proper relational model, instead of SQL, because my personal little ORM implements it for me ;)
Eivind.
The other kind of situation - the one you describe - has also happened, of course. However, in my experience, that's a much less common situation. Maybe a 10% situation. Of course, what's likely is that we work in different kinds of environments - I mostly work with fairly small or fairly young companies, or supplying new systems.
My point is just that there is a "good living" to be made for a web framework in that area. Enough so that Rails don't need to support the other kind of app to be useful and thrive. (Heck, even the web framework we use at work thrive, and that's maintained by just two people on a part time basis, and does much of the same as Rails. Plus compound keys. Knowing the entire codebase well is a grand plus :)
Eivind.
Eivind.
So you can't use your expertise to make a living for 5 years? Or does you contract have your employer paying you severance for 5 years?
Norway (where I live) has an interesting variant of this: Non-competes are enforceable, but ONLY if the former employer pay you full salary (including benefit) for the non-compete period. I know of only one company that has actually done this in practice - it led to some friends of mine getting a year off with full pay. ("You say we get a year of vacation with pay if we resign and start working for XXX? Damn, that just was a good offer.")Eivind.
Eivind.
I also find the entire concept somewhat specious, since it assumes that you can prove that something isn't possible to add to or delete from to get another function. This seems roughly impossible to prove even for a single case; it only can be disproven case by case, and even when it isn't disproven that doesn't really show anything beyond "nobody yet having found a way to disprove it for this particular case", not a demonstration that "this particular case cannot be disproven".
That's how I see the problem, at least.
Eivind.
Three examples:
First, a stream cipher. A stream cipher is a cipher that generate a pseudorandom stream of data, which you then XOR with your data stream. The most well-known stream ciphers are RC4 (used in e.g. SSL) and the one-time pad (having a bunch of true random data you XOR with your data, where the random stream is the same length as your data). The attack here is that the attacker can randomly flip bits in your data, at whatever offset he choose.
Second, a standard block cipher, employed in block-at-a-time mode (Electronic Codebook - ECB - Mode). Most standard symmetric ciphers are block ciphers - on encrypt, they take one block of plaintext (uncrypted data) and a key and produce an encrypted block (ciphertext); on decrypt, they take a block of ciphertext and a key and produce corresponding the plaintext block. In "block at a time mode" you just sequentially split the plaintext into blocks, encrypt each block with the key, and write it to the output. There are three weaknesses here: First, the attacker can replace blocks of your data with other blocks of your data, even if he can't know the content of the data. If the data is highly structured and he knows the structure, he may be able to do a targetted attack by replacing a block. Secondly, he may randomly trash a block. Again, problem with structured data. Thirdly, he may learn of the content of the data by learning which blocks are equal. This is a significant information leak, which can help with the two modification attacks above (and is very unfortunate in its own right). This brings us to the third large example, which is
Third example, a block cipher used in block chaining (CBC) mode. Here, each block of plaintext is XORed with the previous block of ciphertext before being encrypted. This is probably the most common way to use block ciphers, as they are no longer vulnerable to the information leak above. In CBC mode, a one bit corruption in a ciphertext block will trash the corresponding decrypted data block - and cause a controlled one-bit change in the next data block. Without integrity checking, this can be VERY unfortunate.
There are other block cipher modes available, with other properties, including some that are supposed to provide integrity. I am not really familiar with those, so I'll stop here. The point was just to show that you absolutely have to take integrity into considering; the symmetric crypto doesn't give it to you for free, at least not in many significant cases.
Eivind.
By publicly stating an opinion you are bearing witness.
By the kind of witness you are bearing, you show that you have not carefully studied the evidence WRT evolution.
The 7th commandment is not "Thou shalt not bear false witness unless there's a spot of bother to find out what the truth is".
So: Be a good Christian. Delay your witness until you have carefully studied the evidence.
Eivind.
Eivind.
Eivind.
Eivind.
Eivind.
This do, though, increase the scope quite a bit, as it means people can't use religion as a basis for a kind of action that end up hurting people, even when the damage is non-intentional. With that constraint, I feel religion as OK, and a solace and inspiration for people (even though I am an atheist myself.)
Eivind.
That means your questions includes assumptions that makes them wrong. Please learn more about the issues, and you will get better questions. The process of educating you about these areas is longer than I can do in a single, simple post - I'll just say that there are a ton of information out there that will make you get better questions :) It is also very much fun to learn.
Eivind.
Cramer's transactional interpretation, on the other hand, handles all of this elegantly, and the only change it does is assuming a kind of handshake particle running backwards in time at the speed of ligth. Given that we have no time at the speed of light (given relativity), this seems nicely intuitive.
Eivind.
Eivind.
You seem to be misreading more or less on purpose. And you also seem to be doing the standard GPL crosstalk that the GPL increase free software, which works under an assumption that companies do the same development on a free codebase regardsless of the license; they would do the development and release a proprietary product if it wasn't for the GPL, and with the GPL they do the same development and release it for everybody to use. Think carefully on this assumption - when you do, I'm sure you'll agree that it is wrong. And the GPL "causing more free software" is for the most part dependent on that assumption. (There are other, indirect ways that the GPL can cause development - for instance, it keeps the people that are paranoid of being "exploited" comfortable, which sometimes is a boon.)
Eivind.
At least as far I can tell from a quick check, and that match my somewhat vague memory.
Eivind.