If the setting is well known and recognizable, it has more protection than if it is just the same setting in a random work. It is the same concept as where a famous character like Sherlock Holmes can get protection as a character not just as part of an individual work. Star Trek is about as recognizable a setting as you can get. It is not realistic to expect the setting to be seen as original, as non-derivative. But that said, they only have to prove that it is the same setting as one of the episodes. That is a low bar, not a high bar, when the value of the derivative to the fans is based on it being in the same setting. The argument you're trying to make would require you to convince the court that it isn't even a Star Trek "fan film," that it is in a generic or original sci-fi setting. If that were true, and they were being falsely accused of similarity, then it would be a different case. But it isn't.
Repeating the word "exact" and expecting the law to be fatally stuck on minor word definitions is a standard laymans mistake. The law is only hung up on definitions of technical legal words; the vast majority of the words involved are plain English words, and the court doesn't get narrowly pedantic over them. Any of the related Star Trek works are suitable to cite as the original. There isn't any narrow requirement of naming that you seem to imply. "I know a man-trap when I see one" is the sort of legal standard that any judge applies here; if it is a derivative depends mostly on perception, it isn't a procedural type of issue. And the burden is on the copyright owner to demonstrate that it is a derivative, which is a positive requirement for them; they have to show that it is derivative. That doesn't mean the defense has to agree, or gets to argue some pedantic blah-blah; they're not the ones proving it, so all they can do is argue with what the copyright holder proposes as their proof that it is derivative. And so they'll be able to prove that easily based on a wide variety of things of their choice. You're worried about "which exact" episode, but they can actually name as many as they want and they don't have any expectation to limit their argument to 1 episode, or a particular episode. They have the copyright to each of their episodes, and if you carefully craft a derivative to draw elements from the whole series with only a few elements from each episode, that doesn't help you to refute their arguments that you created a derivative work.
My advice is to read all the court rulings in a copyright case some time. And I don't mean blog posts about it; I mean all the things written by the Judge. For a whole case. Then later when half of those things that the judge wrote get thrown out by the appeals court, read what that court actually wrote. You'll find that the legal principles are strict and narrow, but the parties don't get to use narrow gotcha type of arguments about the meanings of the words. All the words with narrow meanings have narrow meanings because of the way the judges use those words, not because of how the parties desire to use them.
People who just discovered Timothy Leary and want to control the pixels they look at, but haven't figured out how yet? Or, just sensible people who dislike bullshit don't know how to internet.
The specifics is, the technology wasn't working, she was traveling, she needed to communicate normally-secure travel plans, and they used a non-secure channel. None of it was classified at the time, it gets a classification afterwards. But it was sensitive information, because it affects her security. But those are decisions you have to make when traveling and the "secure channel" is broken. If you just hunker down whenever that happens, that also creates a security risk.
None of the "accusations" involve documents that were classified at the time.
That's all nonsense, I use static glibc at work frequently, there is no problem. The whole concept is still just horseshit. You admit you don't actually understand these things, so give it a rest. You didn't understand what you read, or it was just wrong. And LGPL is only a linking problem for mixing free software and non-free software, it doesn't have to do with the way that people actually use libraries. You can, for example, simply select a BSD-licensed libc. GCC won't care. You generally recall stuff from 10-15 years ago that you didn't understand then, and don't understand now.
You didn't claim that "there is a contradiction in the trends," you claimed that "by and large the toolchains removed the easy way to statically link things to force dynamic" and then you tried "my point was that the gcc toolchain started pushing hard *against* static linking" which was also not true.
There is no "once again." Things have been getting both static and dynamic linked all along. dynamic *is* better for commonly used system libraries that have stable APIs. Static linking is preferred for uncommon libraries that aren't going to be on the system, and for legacy crapware with conflicting APIs and no backwards compatibility.
And as for "Nowadays you don't see the '.a' libraries generally built" I can say: # locate -r '\.a$' | wc -l 2698
Sure I do. You let slip that you're not a developer, so maybe that is the only reason you don't see which libraries get installed, and what toolchain options are available?
Well my point was that the gcc toolchain started pushing hard *against* static linking, and nowadays there's a hard push *for* static linking (not from gcc mind you). Things keep swinging back and forth, seemingly each iteration having people totally forget why it went the way it is last time.
Well, then your point is complete hogwash, the gcc toolchain has no trouble at all with static linking, and it doesn't push for you to link one way or another. How would it even try? There isn't a GUI to pop up warnings, it doesn't ask you to please reconsider, so... what? What does it do to get in the way of static linking? When those of us who use gcc frequently want to static link, what barrier is in our way?
You're waving your hands and asserting there is a problem, but it doesn't exist. It not only doesn't "push hard *against* static linking" it doesn't even push at all. It is happy to do static linking. In fact, the exact same commands used to do static linking with the gcc toolchain in the 90s... still work. Makefiles from that era still work, including the bits about choosing static linking.
Well, it is curious that you respond to not understanding what was written by claiming it is "nonsensical." It is one of those funny types of responses; you'd have to understand it to know it was nonsense, but if you think it is nonsense you didn't understand it.
3rd party apps is where that sort of thinking will get your system full of malware. That stuff should come from trusted repositories, and should use normal system resources.
This is useful for servers and software developers, where you have trusted legacy code that needs a silly version of something.
Good or bad here depends entirely on trust. And trust is bad. This smooths out the worst forced case where you can't just switch to something that is maintained. Apps generally run in a restricted, safer environment. This is for real software, so that would be dangerous from 3rd parties.
I'm still using the same toolchains as before, and I can still do all the same things as before, plus new things.
Whatever tools you're using, know this: there are other ways that exist in the world. Don't listen to them, you never have to change paradigms if you don't want to. Now, SysV sucked in almost every way, but it was the best we had. No longer true. But it is still there if you like it. All the old tools still work. Some people even hate dbus, but mostly not people who would otherwise be using SysV IPC.
If it works, don't change it. If it sucked from the start, change one time. Like switching from sendmail to postfix, or oracle to postgres. You only have to change one time. foocc to gcc, csh to bash, etc. And I liked csh. If I liked ksh, I'd still be using it.
At least I can understand the systemd complaining, because most distros don't support sysvinit or upstart anymore.
That's just horseshit, distros still support SysV init. Why are you still recycling these lies, even after they've been refuted again and again?
No, package dependencies don't mean you have to use it, it means that it will be installed because nobody competent actually has a use case for removing the dependency and managing the extra packages. (Just pre-empting the usual follow-up lie)
Well, no, thankfully. "ported" of course doesn't mean "switched to." This is significantly misleading, but it will at least help with packages that don't have support on multiple distros. Not surprising when the headline writer thinks "yum" is still one of the package managers...
Etymology is for informational purposes only; it does not dictate meaning, nor is the source of meaning. The source of meaning is how the words are used in modern language.
Because humans don't arrive at close enough answers to each other to avoid fighting; whatever Gods there are or aren't, we know there are is not a God who appears before us in an unambiguous and educational way. Worry about questions of God lead to worrying about questions of what happens after death, and there isn't going to be a good answer. Nor is there a clear expectation of even having a belief.
And if you don't believe in a God already, then it is a silly question because it didn't arise from anything. Were you walking down the path and God appeared in the Sky and now you have questions, or did some humans just make bare assertions about something. Reject bare assertions in the first place, is the logical thing. There is no reason to expect them to be testable.
If you start from the same questions that the Ancients were asking in creating the Gods, you get better answers these days. "Why does the Sun rise in the morning?" "Why is there lighting today?" "When will it rain?" "Where can our people find food?" I understand why God came up in the first place in the attempt to answer these questions, but it not a guarantee that "Is there a God?" arises as a natural question out of daily life. These are the good questions; and if you believe in God, you can have Faith that these questions that have answers are the ones you were supposed to ask. And other people won't worry about it.
You do the same with unicorns too? How about invisible green elves living in the bottom of the garden?
Yes, absolutely. It is not a useful question. The same as questions about God. A bad question like, "is there an invisible green[sic] elf in my garden?" isn't going to be improved by insisting the answer is "no." How would you even check? The best you can do is a plain assertion that there is no invisible green elf in the garden. Or you can argue about the impossibility of being both invisible and green at the same time. Or you can simply reject the question entirely because it is not a good question, it did not arise out of a human cause. There is no reason to even make an assertion about it. Whereas if a person says they were driving down the road and say a unicorn run by, is it possible, I would say yes it is very possible, you can even rent a pony with a prosthetic horn for parties. If you start by only trying to answer questions that came about for a good reason, such as observational curiosity, or a task of some sort, then the only time you'll need to worry about questions regarding invisible elves is when the topic is mental health.
Surely if you believe that the existence or non-existence of god is unknowable then you don't think the question is open?
The Buddhist answer is that it doesn't matter what the answer to that question is, asking it will bring suffering. It may or may not be knowable, but taking a stand one way or the other is going to plant seeds of suffering. Or to put it another way, the question being open brings suffering, the same as answering the question.
Keep in mind, that is a teaching by a Theist. He believed in Gods, but he didn't think there was earthly value in trying to know about Gods and their ways. Humans might be able to learn some things about it, or not, but they won't be able to understand it in a useful way.
Slashdot Mirror
Some consumers worship change believing that every change is an "innovation."
Try a lobotomy, then reconnect your parser with a MOSFET to regulate the gain.
In the old days, these guys were using the same distro as me and would also show up in the help forums.
Most of them finally moved on. Thank you systemd! Thank you RedHat.
If the setting is well known and recognizable, it has more protection than if it is just the same setting in a random work. It is the same concept as where a famous character like Sherlock Holmes can get protection as a character not just as part of an individual work. Star Trek is about as recognizable a setting as you can get. It is not realistic to expect the setting to be seen as original, as non-derivative. But that said, they only have to prove that it is the same setting as one of the episodes. That is a low bar, not a high bar, when the value of the derivative to the fans is based on it being in the same setting. The argument you're trying to make would require you to convince the court that it isn't even a Star Trek "fan film," that it is in a generic or original sci-fi setting. If that were true, and they were being falsely accused of similarity, then it would be a different case. But it isn't.
Repeating the word "exact" and expecting the law to be fatally stuck on minor word definitions is a standard laymans mistake. The law is only hung up on definitions of technical legal words; the vast majority of the words involved are plain English words, and the court doesn't get narrowly pedantic over them. Any of the related Star Trek works are suitable to cite as the original. There isn't any narrow requirement of naming that you seem to imply. "I know a man-trap when I see one" is the sort of legal standard that any judge applies here; if it is a derivative depends mostly on perception, it isn't a procedural type of issue. And the burden is on the copyright owner to demonstrate that it is a derivative, which is a positive requirement for them; they have to show that it is derivative. That doesn't mean the defense has to agree, or gets to argue some pedantic blah-blah; they're not the ones proving it, so all they can do is argue with what the copyright holder proposes as their proof that it is derivative. And so they'll be able to prove that easily based on a wide variety of things of their choice. You're worried about "which exact" episode, but they can actually name as many as they want and they don't have any expectation to limit their argument to 1 episode, or a particular episode. They have the copyright to each of their episodes, and if you carefully craft a derivative to draw elements from the whole series with only a few elements from each episode, that doesn't help you to refute their arguments that you created a derivative work.
My advice is to read all the court rulings in a copyright case some time. And I don't mean blog posts about it; I mean all the things written by the Judge. For a whole case. Then later when half of those things that the judge wrote get thrown out by the appeals court, read what that court actually wrote. You'll find that the legal principles are strict and narrow, but the parties don't get to use narrow gotcha type of arguments about the meanings of the words. All the words with narrow meanings have narrow meanings because of the way the judges use those words, not because of how the parties desire to use them.
Don't worry, dancing cats will always stand out.
People who just discovered Timothy Leary and want to control the pixels they look at, but haven't figured out how yet? Or, just sensible people who dislike bullshit don't know how to internet.
The specifics is, the technology wasn't working, she was traveling, she needed to communicate normally-secure travel plans, and they used a non-secure channel. None of it was classified at the time, it gets a classification afterwards. But it was sensitive information, because it affects her security. But those are decisions you have to make when traveling and the "secure channel" is broken. If you just hunker down whenever that happens, that also creates a security risk.
None of the "accusations" involve documents that were classified at the time.
This was the one chance to get Gary Hart elected, and we let it pass!
The one Democrat that could lose to Trump: Anthony Weiner.
Good news for Weinie though, his wife can get him into the White House parties.
His approval rating is at 29%, which is about the same as the approval rating of the mosquitoes that carry Zika virus.
That does at least make him more popular than Congress.
Governator was a moderate with a lot of Democratic supporters. "If I'm paying a lot of taxes, I must be making a lot of money."
No comparison at all. He's even a Kennedy by marriage.
That's all nonsense, I use static glibc at work frequently, there is no problem. The whole concept is still just horseshit. You admit you don't actually understand these things, so give it a rest. You didn't understand what you read, or it was just wrong. And LGPL is only a linking problem for mixing free software and non-free software, it doesn't have to do with the way that people actually use libraries. You can, for example, simply select a BSD-licensed libc. GCC won't care. You generally recall stuff from 10-15 years ago that you didn't understand then, and don't understand now.
You didn't claim that "there is a contradiction in the trends," you claimed that "by and large the toolchains removed the easy way to statically link things to force dynamic" and then you tried "my point was that the gcc toolchain started pushing hard *against* static linking" which was also not true.
There is no "once again." Things have been getting both static and dynamic linked all along. dynamic *is* better for commonly used system libraries that have stable APIs. Static linking is preferred for uncommon libraries that aren't going to be on the system, and for legacy crapware with conflicting APIs and no backwards compatibility.
And as for "Nowadays you don't see the '.a' libraries generally built" I can say:
# locate -r '\.a$' | wc -l
2698
Sure I do. You let slip that you're not a developer, so maybe that is the only reason you don't see which libraries get installed, and what toolchain options are available?
Well my point was that the gcc toolchain started pushing hard *against* static linking, and nowadays there's a hard push *for* static linking (not from gcc mind you). Things keep swinging back and forth, seemingly each iteration having people totally forget why it went the way it is last time.
Well, then your point is complete hogwash, the gcc toolchain has no trouble at all with static linking, and it doesn't push for you to link one way or another. How would it even try? There isn't a GUI to pop up warnings, it doesn't ask you to please reconsider, so... what? What does it do to get in the way of static linking? When those of us who use gcc frequently want to static link, what barrier is in our way?
You're waving your hands and asserting there is a problem, but it doesn't exist. It not only doesn't "push hard *against* static linking" it doesn't even push at all. It is happy to do static linking. In fact, the exact same commands used to do static linking with the gcc toolchain in the 90s... still work. Makefiles from that era still work, including the bits about choosing static linking.
dnf replaced yum as the default package manager starting with Fedora 22.
Well, it is curious that you respond to not understanding what was written by claiming it is "nonsensical." It is one of those funny types of responses; you'd have to understand it to know it was nonsense, but if you think it is nonsense you didn't understand it.
3rd party apps is where that sort of thinking will get your system full of malware. That stuff should come from trusted repositories, and should use normal system resources.
This is useful for servers and software developers, where you have trusted legacy code that needs a silly version of something.
Good or bad here depends entirely on trust. And trust is bad. This smooths out the worst forced case where you can't just switch to something that is maintained. Apps generally run in a restricted, safer environment. This is for real software, so that would be dangerous from 3rd parties.
I'm still using the same toolchains as before, and I can still do all the same things as before, plus new things.
Whatever tools you're using, know this: there are other ways that exist in the world. Don't listen to them, you never have to change paradigms if you don't want to. Now, SysV sucked in almost every way, but it was the best we had. No longer true. But it is still there if you like it. All the old tools still work. Some people even hate dbus, but mostly not people who would otherwise be using SysV IPC.
If it works, don't change it. If it sucked from the start, change one time. Like switching from sendmail to postfix, or oracle to postgres. You only have to change one time. foocc to gcc, csh to bash, etc. And I liked csh. If I liked ksh, I'd still be using it.
At least I can understand the systemd complaining, because most distros don't support sysvinit or upstart anymore.
That's just horseshit, distros still support SysV init. Why are you still recycling these lies, even after they've been refuted again and again?
No, package dependencies don't mean you have to use it, it means that it will be installed because nobody competent actually has a use case for removing the dependency and managing the extra packages. (Just pre-empting the usual follow-up lie)
yum was already replaced.
Well, no, thankfully. "ported" of course doesn't mean "switched to." This is significantly misleading, but it will at least help with packages that don't have support on multiple distros. Not surprising when the headline writer thinks "yum" is still one of the package managers...
Etymology is for informational purposes only; it does not dictate meaning, nor is the source of meaning. The source of meaning is how the words are used in modern language.
Because humans don't arrive at close enough answers to each other to avoid fighting; whatever Gods there are or aren't, we know there are is not a God who appears before us in an unambiguous and educational way. Worry about questions of God lead to worrying about questions of what happens after death, and there isn't going to be a good answer. Nor is there a clear expectation of even having a belief.
And if you don't believe in a God already, then it is a silly question because it didn't arise from anything. Were you walking down the path and God appeared in the Sky and now you have questions, or did some humans just make bare assertions about something. Reject bare assertions in the first place, is the logical thing. There is no reason to expect them to be testable.
If you start from the same questions that the Ancients were asking in creating the Gods, you get better answers these days. "Why does the Sun rise in the morning?" "Why is there lighting today?" "When will it rain?" "Where can our people find food?" I understand why God came up in the first place in the attempt to answer these questions, but it not a guarantee that "Is there a God?" arises as a natural question out of daily life. These are the good questions; and if you believe in God, you can have Faith that these questions that have answers are the ones you were supposed to ask. And other people won't worry about it.
You do the same with unicorns too? How about invisible green elves living in the bottom of the garden?
Yes, absolutely. It is not a useful question. The same as questions about God. A bad question like, "is there an invisible green[sic] elf in my garden?" isn't going to be improved by insisting the answer is "no." How would you even check? The best you can do is a plain assertion that there is no invisible green elf in the garden. Or you can argue about the impossibility of being both invisible and green at the same time. Or you can simply reject the question entirely because it is not a good question, it did not arise out of a human cause. There is no reason to even make an assertion about it. Whereas if a person says they were driving down the road and say a unicorn run by, is it possible, I would say yes it is very possible, you can even rent a pony with a prosthetic horn for parties. If you start by only trying to answer questions that came about for a good reason, such as observational curiosity, or a task of some sort, then the only time you'll need to worry about questions regarding invisible elves is when the topic is mental health.
Surely if you believe that the existence or non-existence of god is unknowable then you don't think the question is open?
The Buddhist answer is that it doesn't matter what the answer to that question is, asking it will bring suffering. It may or may not be knowable, but taking a stand one way or the other is going to plant seeds of suffering. Or to put it another way, the question being open brings suffering, the same as answering the question.
Keep in mind, that is a teaching by a Theist. He believed in Gods, but he didn't think there was earthly value in trying to know about Gods and their ways. Humans might be able to learn some things about it, or not, but they won't be able to understand it in a useful way.
Netslaves never have a nice day?
You should be trying to advance to higher caste in the New Media World Order or whatever they call it now