So in the US the right to live only applies to US citicens?
Re:Here in MN it's possible to block ads in yards.
on
Why Do You Block Ads?
·
· Score: 2, Interesting
It's illegal to post a non real estate, political or garage sale sign in your own front yard.
And you think that's a good thing in a supposedly free country? I should have the right to put whatever I want in my yard as long as it doesn't violate "community standards" for obscenity.
Well, it should be easy to circumvent: Say you want to put up a sign "Get Firefox!", then instead make a sign which says:
[small]I demand my political right to put up a sign saying[/small] [big]Get Firefox![/big] [small]in my own front yard![/small]
This is clearly a political sign, and therefore shouldn't be a problem.:-)
Ok, so far for the theory part:-) Of course, a successful OSS project is very much about things like code reuse and community (if you are developing your software alone and from scratch, and don't intend to change that ever, OSS licensing doesn't get you any advantage). Also, for OSS, the development processes are usually different, because it's driven mostly by volunteers, and therefore you cannot simply command what to do, which makes OSS projects much more democratic than closed source projects (which doesn't mean that they are completely democratic; after all, there's still the distinction between those who have access to the repository and those who don't; OTOH, if the maintainers use this position in a way the community doesn't like, they risk a fork followed by a developer drain (see the egcs project as example). Indeed, forking is mostly an OSS topic: While proprietary software in principle could fork as well, the probability is quite low because to fork a project you need the source code and the right to develop it on your own; especially the second is something you'll have a hard time to get from a company.
You mean law (including copyright law) isn't the domain of the courts? Or do you imply that it doesn't work out well for the courts?
BTW, the GPL would be a bad model for scientific publications, because it's created for code. Better use something aiming at content, like the GFDL or the Creative Commons licenses.
I think the reason is that in seeking for more fundamental theories in particle physics we get theories which imply there are some particles we don't know yet. Therefore it's not too unlikely that there is a form of matter we don't know yet, and there's no known reason that it may not be enough to be relevant in large scale structures. Therefore, introducing dark matter means introducing something which we might well have to introduce anyway. Changing the law of gravitation means doing another, independent change. Therefore, introducing dark matter is the simpler solution. Moreover, dark matter has a better testability (because we can search for new particles in our accelerators).
What astonishes me is that a GR calculation seems to be done only now: I would have expected this to be the first thing to check before introducing anything new, be it dark matter or modified laws of physics.
Disclaimer: I'm neither in astrophysics nor in particle physics, therefore the above is just an educated guess.
Back in the day, the prevailing theory was that the planets were attached to the crystal spheres and travelled in perfect circles. When the data didn't fit, they proposed adding epicycles to the circular paths. When that didn't work, they added more and more circles, increasing the complexity of the theory. Then Copernicus came along and pointed out that it was not so complicated at all... the planets just travelled in ellipses.
Wrong. Copernicus still had the planets moving in circles. The big difference (and the reason of the rejection by the church) was that in his model he put the sun instead of the earth in the center. It was Kepler who found that the planets don't really move in circles, but in ellipses.
Tell me again, is the universe expanding or contracting? Would your answer be different in 1998? 1972? 1950? 1900?
According to current knowledge, it's expanding. According to current knowledge, it was also expanding in 1900. However, in 1900's knowledge there was not yet any known sign for such an expansion, therefore according to the knowledge of then one had to conclude it didn't expand (and according to that knowledge it wouldn't expand today).
Now it's entirely possible (although very unlikely, but then, before 1900 the same would have been said about Newtonian physics not being the correct framework for the description of the universe) that tomorrow we learn something new which lets us see our observations in a new light, and therefore conclude that our previous derivation of universal expansion was based on an error we couldn't know then. But in case that happened, it would not mean that we just go back to an earlier model. It would mean we had learned something new. The new model would not only describe a non-expanding universe, but a non-expanding universe which looks as if it would expand.
Of course the whole previous paragraph is purely hypothetical, since we don't yet have any evidence which would let us conclude that the observed expansion isn't real.
And the thing is, they can keep this up because no one catches them.
Wrong.
Let's say a scientist says "40 billion years ago, Y happened."
Well, it's unlikely a scientist would say so, because according to out current knowledge the universe didn't exist that long. But well, let's change it to 10 billion years.
Is he really afraid someone's going to go back in time and prove him wrong?
No. But he is afraid that someone comes along and says e.g.: "Hey, if that had happened, then it would have caused a massive production of Lithium, but our spectral data shows no sign of that Lithium." In which case he better has a very good argument why the Lithium hasn't been found.
4 - After the requirements are requested and the specs/design is created don't let users change them. I can't change everything just because a user changes their mind. If I have to change, the release date is pushed back as if I just started the design today. I can't complete a program until you are done knowing what you want it to do.
I'd say as an absolute, this is a sure way to get out of business. Imagine, you're an architect, and after the house is half-built, the customer asks for a change. Now, how would you react? Surely not with "sorry, the design has been fixed, I won't change it now!" Instead you probably would first check if it changes anything which exists yet (for example, if you are currently building the basement, and the customer asks for a small change of some window at the second floor, it would be plain silly to reject the change just for princpiple, or demand more time for that change; OTOH if the building is almost finished, and the customer tells you he would like to increase the ground area a bit, you'd of course tell him that it's not doable with reasonable effort). And then, you'd check how much it will change it (if he asks e.g. just for a second power outlet besides an existing one, there's no reason not to do it, but if he asks for a complete redesign of the ground plan, you'll of course reject it or basically demand a restart and covering of all the additional costs).
Of course, you'll then have to prove that the program generated proof is correct (because the proof generating program could be buggy as well). And if you do that with a proof checking program as well, you must prove that the proof checking program is correct. Not only at the source code level, but the actual running code on the actual machine (because it could be translated by a buggy compiler, or be running on a buggy processor).
Even if you formally prove that your software is correct, it may still be erroneous, for several reasons:
Your proof may be erroneous (of course, you can add another step and prove that your proof is correct, but while that again raises the probability of your code being correct, it's still not 100%)
What you proved may not be sufficient (e.g. you may prove that your TCP/IP stack will always work correctly, but in practice it may be completely useless because it's just so damned slow)
The axioms your proof is based on (which includes the specification of your program, as well as assumtions for the system it runs on) may be wrong (as a simple example, if you have the assumption that all input you receive from the net conforms to a certain protocol you'll never catch bugs which only occur with incorrect input, and your proof doesn't help you because this assumption is buried in that proof as well as in your code)
But then, one would have to define the term "bug" much more strictly.
To make an example: The WTC was designed to survive an airplane crash. Now, 9/11 showed that it didn't survive that airplane crash. Was that a bug in the building? Well, no, it wasnt. The design was explicitly to survive a crash with the largest airplane which existed at the time it was built.
The corresponding for OS virus resistance would be: "The OS is immune to all viruses known today." Now, if tomorrow a new virus appears and manages to infect your OS, would you then consider it a bug in the OS? I bet so.
Similar things are also true for other aspects. For example, for every bridge, you have a specification of the maximum weight of vehicles on it. If you build a pedestrian's bridge, and then when someone drives over it with a tank, you'll not be responsible. The bridge was not designed for that. Just as for every bridge there's a weight which will break it, for every word processor there's a document size on which it will fail one way or another. Now, where's your specification on how long your texts may be? Or taken from a different angle, if after a Word crash, MS simply said "well, Word wasn't designed for texts which are that large", wouldn't you consider it just a lame excuse?
If there is to be liability on bugs, there must be first and foremost a precise definition of what is a bug, and what simply is a case the software was not designed for.
It takes a genius to write an amazing program like TeX or Emacs, but no genius is required to write a program that is free of bugs.
Indeed, I've even written software which was absolutely bug-free on the first compile, and it didn't even take me much time. Now, in order you want to know what marvellous piece of software that was: It was a ground-breaking software to write the words "Hello world!" to standard output. Unfortunately after I had written it, I had to find out that there's just no market for that type of program. Even the GNU version of it apparently only survived because they included a mail reader (thus making it bloatware). Well, it seems that the market doesn't value perfect software, after all...
If they get this through, it's not enough not to buy their shit. You may not even seek for it. Or for something with a similar name: Say, someone wrote a (non-RIAA) song titled "the blue madonna", and you want to seek for it, but don't remember the "blue" part. What would you type in the search engine? Right: "madonna". Result (if that would get through): Money for the RIAA.
Ok, I stand corrected: The software is better than I thought. But then, strictly speaking I was still right because I always wrote AFAIK, and it did indeed represent my (faulty, as I now know) state of knowledge of the time when I wrote it.:-)
But then, I think such links still can go dead if the page in question gets deleted. Or if that specific version gets deleted due to a copyright infringment (yes, that has happened, at least in the German Wikipedia).
That was not a move, that was an edit which manually replaced the article with a redirect. Indeed, the page you claim it was moved to already existed before you even created your article. Which couldn't be the case if the article was moved there.
In case you don't understand: Moving is not editing both articles and transferring the text with cut/paste between them; moving an article means using the corresponding function (I don't know the English name because it's only shown if you're logged in and I don't have an account on the English version of Wikipedia, but I guess it's called either "move" or "rename"; if you didn't change your skin, it should be an extra tab at the top of the article). Note that the moved article still contains all the history (which is the reason why moving is preferred to copying the content, if possible, especially if there is a good chance that the original article will get deleted after that). Moving the article changes the name of the old article to the new name, and creates a new one which is just a redirect.
In short, your example doesn't disprove my point because it's not the situation I've been talking about.
Using a dependency tree approach doesn't mean it's not single thread. For example, the single thread could do a topological sort on the dependency graph, and then execute the corresponding linear list of start scripts one after the other. OTOH, a multithreaded boot could just start every startup script with the same number in parallel, wait for all of them to finish, and then go on with the next startup script.
Now I don't know if OS X and Solaris use single or multi threaded boot, but them using a dependency tree aproach doesn't tell you (they could e.g. use that approach simply because it's easier to maintain the boot process this way, because you don't have to manually determine the order).
Slashdot Mirror
If you apply that rule to Linux, then it's clear:
Ok, now we just have to find out what it means to linux a video
You mean like this?
So in the US the right to live only applies to US citicens?
Well, it should be easy to circumvent:
Say you want to put up a sign "Get Firefox!", then instead make a sign which says:
[small]I demand my political right to put up a sign saying[/small]
[big]Get Firefox![/big]
[small]in my own front yard![/small]
This is clearly a political sign, and therefore shouldn't be a problem.
Ok, so far for the theory part
Of course, a successful OSS project is very much about things like code reuse and community (if you are developing your software alone and from scratch, and don't intend to change that ever, OSS licensing doesn't get you any advantage). Also, for OSS, the development processes are usually different, because it's driven mostly by volunteers, and therefore you cannot simply command what to do, which makes OSS projects much more democratic than closed source projects (which doesn't mean that they are completely democratic; after all, there's still the distinction between those who have access to the repository and those who don't; OTOH, if the maintainers use this position in a way the community doesn't like, they risk a fork followed by a developer drain (see the egcs project as example). Indeed, forking is mostly an OSS topic: While proprietary software in principle could fork as well, the probability is quite low because to fork a project you need the source code and the right to develop it on your own; especially the second is something you'll have a hard time to get from a company.
You mean simple fluid problems like the flow of Helium at a few Kelvin above zero? :-)
Don't forget to film it and watch the movie backwards!
You mean law (including copyright law) isn't the domain of the courts? Or do you imply that it doesn't work out well for the courts?
BTW, the GPL would be a bad model for scientific publications, because it's created for code. Better use something aiming at content, like the GFDL or the Creative Commons licenses.
I think the reason is that in seeking for more fundamental theories in particle physics we get theories which imply there are some particles we don't know yet. Therefore it's not too unlikely that there is a form of matter we don't know yet, and there's no known reason that it may not be enough to be relevant in large scale structures. Therefore, introducing dark matter means introducing something which we might well have to introduce anyway. Changing the law of gravitation means doing another, independent change. Therefore, introducing dark matter is the simpler solution. Moreover, dark matter has a better testability (because we can search for new particles in our accelerators).
What astonishes me is that a GR calculation seems to be done only now: I would have expected this to be the first thing to check before introducing anything new, be it dark matter or modified laws of physics.
Disclaimer: I'm neither in astrophysics nor in particle physics, therefore the above is just an educated guess.
Wrong. Copernicus still had the planets moving in circles. The big difference (and the reason of the rejection by the church) was that in his model he put the sun instead of the earth in the center.
It was Kepler who found that the planets don't really move in circles, but in ellipses.
Ok, then how strongly do your skateboard and you attract each other?
According to current knowledge, it's expanding. According to current knowledge, it was also expanding in 1900. However, in 1900's knowledge there was not yet any known sign for such an expansion, therefore according to the knowledge of then one had to conclude it didn't expand (and according to that knowledge it wouldn't expand today).
Now it's entirely possible (although very unlikely, but then, before 1900 the same would have been said about Newtonian physics not being the correct framework for the description of the universe) that tomorrow we learn something new which lets us see our observations in a new light, and therefore conclude that our previous derivation of universal expansion was based on an error we couldn't know then. But in case that happened, it would not mean that we just go back to an earlier model. It would mean we had learned something new. The new model would not only describe a non-expanding universe, but a non-expanding universe which looks as if it would expand.
Of course the whole previous paragraph is purely hypothetical, since we don't yet have any evidence which would let us conclude that the observed expansion isn't real.
Wrong.
Well, it's unlikely a scientist would say so, because according to out current knowledge the universe didn't exist that long. But well, let's change it to 10 billion years.
No. But he is afraid that someone comes along and says e.g.: "Hey, if that had happened, then it would have caused a massive production of Lithium, but our spectral data shows no sign of that Lithium." In which case he better has a very good argument why the Lithium hasn't been found.
What else should it be?
Well, Germany will most likely be soon ruled by a physicist. Although I'm not sure if she is GPL friendly.
I'd say as an absolute, this is a sure way to get out of business.
Imagine, you're an architect, and after the house is half-built, the customer asks for a change. Now, how would you react? Surely not with "sorry, the design has been fixed, I won't change it now!" Instead you probably would first check if it changes anything which exists yet (for example, if you are currently building the basement, and the customer asks for a small change of some window at the second floor, it would be plain silly to reject the change just for princpiple, or demand more time for that change; OTOH if the building is almost finished, and the customer tells you he would like to increase the ground area a bit, you'd of course tell him that it's not doable with reasonable effort). And then, you'd check how much it will change it (if he asks e.g. just for a second power outlet besides an existing one, there's no reason not to do it, but if he asks for a complete redesign of the ground plan, you'll of course reject it or basically demand a restart and covering of all the additional costs).
Of course, you'll then have to prove that the program generated proof is correct (because the proof generating program could be buggy as well). And if you do that with a proof checking program as well, you must prove that the proof checking program is correct. Not only at the source code level, but the actual running code on the actual machine (because it could be translated by a buggy compiler, or be running on a buggy processor).
But then, one would have to define the term "bug" much more strictly.
To make an example: The WTC was designed to survive an airplane crash. Now, 9/11 showed that it didn't survive that airplane crash. Was that a bug in the building? Well, no, it wasnt. The design was explicitly to survive a crash with the largest airplane which existed at the time it was built.
The corresponding for OS virus resistance would be: "The OS is immune to all viruses known today." Now, if tomorrow a new virus appears and manages to infect your OS, would you then consider it a bug in the OS? I bet so.
Similar things are also true for other aspects. For example, for every bridge, you have a specification of the maximum weight of vehicles on it. If you build a pedestrian's bridge, and then when someone drives over it with a tank, you'll not be responsible. The bridge was not designed for that. Just as for every bridge there's a weight which will break it, for every word processor there's a document size on which it will fail one way or another. Now, where's your specification on how long your texts may be? Or taken from a different angle, if after a Word crash, MS simply said "well, Word wasn't designed for texts which are that large", wouldn't you consider it just a lame excuse?
If there is to be liability on bugs, there must be first and foremost a precise definition of what is a bug, and what simply is a case the software was not designed for.
Indeed, I've even written software which was absolutely bug-free on the first compile, and it didn't even take me much time.
Now, in order you want to know what marvellous piece of software that was: It was a ground-breaking software to write the words "Hello world!" to standard output.
Unfortunately after I had written it, I had to find out that there's just no market for that type of program. Even the GNU version of it apparently only survived because they included a mail reader (thus making it bloatware). Well, it seems that the market doesn't value perfect software, after all
SCNR
See, that's why I only believe something if they say it on TV
If they get this through, it's not enough not to buy their shit. You may not even seek for it. Or for something with a similar name: Say, someone wrote a (non-RIAA) song titled "the blue madonna", and you want to seek for it, but don't remember the "blue" part. What would you type in the search engine? Right: "madonna". Result (if that would get through): Money for the RIAA.
Information wants to be anthropomorphized! :-)
Ok, I stand corrected: The software is better than I thought. :-)
But then, strictly speaking I was still right because I always wrote AFAIK, and it did indeed represent my (faulty, as I now know) state of knowledge of the time when I wrote it.
But then, I think such links still can go dead if the page in question gets deleted. Or if that specific version gets deleted due to a copyright infringment (yes, that has happened, at least in the German Wikipedia).
That was not a move, that was an edit which manually replaced the article with a redirect. Indeed, the page you claim it was moved to already existed before you even created your article. Which couldn't be the case if the article was moved there.
In case you don't understand: Moving is not editing both articles and transferring the text with cut/paste between them; moving an article means using the corresponding function (I don't know the English name because it's only shown if you're logged in and I don't have an account on the English version of Wikipedia, but I guess it's called either "move" or "rename"; if you didn't change your skin, it should be an extra tab at the top of the article). Note that the moved article still contains all the history (which is the reason why moving is preferred to copying the content, if possible, especially if there is a good chance that the original article will get deleted after that). Moving the article changes the name of the old article to the new name, and creates a new one which is just a redirect.
In short, your example doesn't disprove my point because it's not the situation I've been talking about.
Using a dependency tree approach doesn't mean it's not single thread. For example, the single thread could do a topological sort on the dependency graph, and then execute the corresponding linear list of start scripts one after the other. OTOH, a multithreaded boot could just start every startup script with the same number in parallel, wait for all of them to finish, and then go on with the next startup script.
Now I don't know if OS X and Solaris use single or multi threaded boot, but them using a dependency tree aproach doesn't tell you (they could e.g. use that approach simply because it's easier to maintain the boot process this way, because you don't have to manually determine the order).