Huh? I guess you don't understand. Every legal copy gets a different watermark, and the buyer is registered. If somebody thinks you have an illegaly copied file, they can trace back to the original buyer, who spread the file.
Now just imagine a Beowulf clust... Ah well, I don't have to write it down explicitely, no? You guys can figure that out by yourself! I'm outta here *slams door*
Truly old news. But I don't do the mental reconstruction thingy, I simply drive backwards. Now if some researcher could come and find out why my way home always takes 10x as long as the way there, I would really be pleased.
My first computer was an Amiga 1000 (PAL version). Ah, endless afternoons (I was about 8 at that time, so I was told to sleep during night) of hacking BASIC. Creating animations with DPaint was fun too. Or writing Amiga-DOS scripts, to automate what ever small task. And sometimes recreation with the FlightSimulator. Oh, the days!
You can hack it in by making a user for every program, but I don't think that should be necessary.
Why not? It doesn't harm the system.
Besides, who'd want to do that?
For example the install scripts or the OS itself.
Such as, read only access to itself and its own directory, write access to an incoming files directory, read/write to its own registry key and the temp folder, outgoing network access to tcp port 80, and that's it. It shouldn't be allowed to spawn child processes, read system information like hostname, username, usergroup, OS version, and it can't because all those permissions were absent from iexplore.acl (but can of course be assigned).
You might be interested in Java then. By the virtue of the Security Manager, you can in fact define for every Java app you run what it is allowed to, and what it is not allowed to do.
For example, using the FilePermission you can restrict the app's read or write access to certain directories only. Analogously, using the SocketPermission you can restrict network access of that program to certain hosts or certain ports only. With an application-specific policy file, you can control the rights of this app extremely fine-grainedly.
Are there any operating systems out there with per-user AND per-process ACLs?
Couldn't that be achieved by running program P with setuid, having an own user named PU and an own group named PG for program P. Now as user U, you could set the UID of directory/home/U/foo/bar/files_of_P to PU (or add PU to the ACL for that directory).
Now, no matter whether user U or V runs P, P only has access to the directories of a user which have UID PU. For users U and V to have full access to these directories, they could simply join group PG.
Support the browsers your target audience uses. Weigh up the cost of adding support for a particular browser against the profit you could make out of these users. If costs are heigher than profits, do not support that particular browser. But also have a look into the future, i.e. if you expect the share of customers using this browser to increase, you may consider adding support now.
Well, in the first dupe you have all the people pointing out it's a dupe. In the second dupe, you have dupes of these comments and also new comments pointing out it's a dupe. It grows exponentially, I'd say. I'd say so too. So do I.
What does the Slashdot community think? Shoud Barry Bonds' record 73 single season homeruns be in the public domain, or should I worry about having to pay royalties for the first part of this compound sentence?
The Slashdot community thinks: stop ending every story with those stupid questions.
the future: everyone in the world is able to write whatever they want, and have it available to anyone else in the world, instantly. [...] in the future vision above - almost no work is required to distribute. written word is literally available as soon as you're done editing. by everyone, for everyone.
If you have authorized five computers, a button labeled "Deauthorize All" will appear in your Account Information screen. This button will deauthorize all computers associated with your account. You can then reauthorize up to 5 computers. Note: You can only use this feature once a year.
Of course, if you suddenly lose access to all your accounts, contact Apple.
The rel="nofollow" is not going to take away the link of the submitter's website, but it's going to stop the abusers who only submit for PageRank whoring. If somebody's interested in the submitter because he/she thinks this person does a god job, then the link can still be followed.
The point is simply that Google will not, thereby saving you (yes, YOU) from crappy search results in case you once want to find something on Google which was unfortunately replaced by unrelated pages through link spamming on Slashdot.
Oh, and being rewarded by increased karma is still worth a lot I guess, not to even think about having your name mentioned on the front page. Slashdot is a community site, from the community for the community. And as such, submitters indeed have a gain inside that community through karma.
Of course, one could also think about further ways of rewarding submitters. Why not giving out some ad-free pages, or other goodies subscribers enjoy (for non-subscribed submitters), or refuelling the ad-free pages acoount a bit if the submitter already is a subscriber. I guess there are plenty more possibilities to reward submitters apart from PageRank, ways which have enough benefit for submitters but much less potential for abusive exploitation.
Let's have a look at the problems that links in stories can create. I think there are merely two classes of problems:
Link spamming
Indirect links
Although I've seen a lot of comments here claiming that link spamming is not a problem, because it can only happen a) with the personal website link and b) with links inside the story blurb (which can't go overboard because they are checked by the editors). Link spamming in comments is not possible because of the automatic addition of rel="nofollow" to links in comment posts (although looking at the page source shows that this is not done in 100% of the cases, but this may just be a Slashcode bug [CmdrTaco, you may want to take a look at it]).
The reasoning here by many users is that the link spamming does not impede their/. experience. This is true. But, it will come back to you, namely when you search Google for something, and the topmost results are all crap, promoted by the said link spamming e.g. on/. (take a look at * * Beatles-Beatles stories and the link to his personal website, which is a disguised link farm). Therefore, accepting link spamming on/. does not disturb your reading of this website, but it will render Googles search system unusable, for the search terms which get promoted by link spamming.
Now on to the second class of problems: indirect links. Indirect links in a story are links to personal blogs which contain a further summary of the original article, which does not add any insights on the original story (this is a common procedure by e.g. Roland Piquepaille (don't confuse his account with that of the equally named troll!)). Instead of linking directly to TFA, these people link to their blogs, which in turn contains a link to TFA. This is annyoing because readers want to go directly to the story source, but it may not necessarily count as link spamming (at least as long as the linked to page is not a link farm). It may though be used to simply drive ad revenue to this person's blog.
What can we learn from these two problem classes:
Link spammingdoes not disturb the immediate/. reading experience, but it hurts the overall network by promoting crap search results on Google.
Indirect linksdo disturb the immediate/. reading experience, but does not affect Googles PageRank system.
Now this is where the rel="nofollow" enters the scene. Applying this attribute to the first class of problematic links does indeed help to extinguish the problem of link spamming. Since as of today, link spamming was mostly done through the means of the personal website link, I'd vote for adding it to that link. Links inside the article body are most of the time only of the second problem class, which cannot be mitigated by the rel="nofollow" attribute. To counter the indirect linking, only manual checking by the editors is of use.
Several comments here have brought up the question of being rewarded for submitting a story by means of increased PageRank. Some think this is legitimate, because these users have taken their time to submit a story. Others think that submitting a story should not be rewarded. This is kind of black and white thinking. I personally think that users should be rewarded for submitting a story, but not by increased PageRank, since this gives too much room for abuse. When reading the other comments here, I think that not many users are aware of the fact that submitters are indeed rewarded for story submitting, namely by gaining karma. This is a fact!
I therefore plead to add the rel="nofollow" attribute to the personal websit
But they are abusing/. to increase their PageRank (like e.g. * *Beatles-Bestles does). This will not disturb your/. reading, but it will come back to you once you're searching Google for something, and the topmost results are all crap, but listed first because of said link spamming!
Looks like ScuttleMoney^H^Hkey still doesn't get it, as well as other Slashdotters. So, let me repost this for the thousandst time.
Interesting thing is, ScuttleMonkey seems to use some standard template for * *Beatles-Beatles submissions, since ALL of them start by: "* * Beatles-Beatles writes to tell us...".
Our reciprocal links page. These links are useful for website promotion, link trades, and generating traffic to your site. There are many sites with useful products, services, programs, business opportunities, information, and free stuff.
All reciprocal links have been manually screened before getting on this page. Webmasters that post links on this page, also promote this Links Page on their site too. If you want to add your link and become a member of this reciprocal links page, just click on the top link for details. It's free to join.
Looking at the link list (just a small excerpt):
Guaranteed Dropship Wholesalers business directory source
Good Vibrations for Singles - Free Dating, Love, Romance, and Friendship
Collection Agency - Williams, Cohen & Gray
Trade Links - Link Swap Page
Personals Dating Affiliate Program - Instant Sign-Up
ProfitsRup2U For Successful Internet Marketing
Trade links page - reciprocal links page
What do we learn? * * Beatles-Beatles is an ugly link spammer who uses Slashdot to increase the PageRank of his own site, on which he hosts a link farm.
Slashdot Mirror
[sarcastic comment about not even getting the Wikipedia link right]
Why not? It doesn't harm the system.
For example the install scripts or the OS itself.
You might be interested in Java then. By the virtue of the Security Manager, you can in fact define for every Java app you run what it is allowed to, and what it is not allowed to do.
For example, using the FilePermission you can restrict the app's read or write access to certain directories only. Analogously, using the SocketPermission you can restrict network access of that program to certain hosts or certain ports only. With an application-specific policy file, you can control the rights of this app extremely fine-grainedly.
Couldn't that be achieved by running program P with setuid, having an own user named PU and an own group named PG for program P. Now as user U, you could set the UID of directory /home/U/foo/bar/files_of_P to PU (or add PU to the ACL for that directory).
Now, no matter whether user U or V runs P, P only has access to the directories of a user which have UID PU. For users U and V to have full access to these directories, they could simply join group PG.
Let's hope it was designed intelligently then...
But seriously, I'd rather have the security problems fixed at the source, instead of having to add layers and layers of so called "security software".
The point is simply that Google will not, thereby saving you (yes, YOU) from crappy search results in case you once want to find something on Google which was unfortunately replaced by unrelated pages through link spamming on Slashdot.
Oh, and being rewarded by increased karma is still worth a lot I guess, not to even think about having your name mentioned on the front page. Slashdot is a community site, from the community for the community. And as such, submitters indeed have a gain inside that community through karma.
Of course, one could also think about further ways of rewarding submitters. Why not giving out some ad-free pages, or other goodies subscribers enjoy (for non-subscribed submitters), or refuelling the ad-free pages acoount a bit if the submitter already is a subscriber. I guess there are plenty more possibilities to reward submitters apart from PageRank, ways which have enough benefit for submitters but much less potential for abusive exploitation.
Let's have a look at the problems that links in stories can create. I think there are merely two classes of problems:
Although I've seen a lot of comments here claiming that link spamming is not a problem, because it can only happen a) with the personal website link and b) with links inside the story blurb (which can't go overboard because they are checked by the editors). Link spamming in comments is not possible because of the automatic addition of rel="nofollow" to links in comment posts (although looking at the page source shows that this is not done in 100% of the cases, but this may just be a Slashcode bug [CmdrTaco, you may want to take a look at it]).
The reasoning here by many users is that the link spamming does not impede their /. experience. This is true. But, it will come back to you, namely when you search Google for something, and the topmost results are all crap, promoted by the said link spamming e.g. on /. (take a look at * * Beatles-Beatles stories and the link to his personal website, which is a disguised link farm). Therefore, accepting link spamming on /. does not disturb your reading of this website, but it will render Googles search system unusable, for the search terms which get promoted by link spamming.
Now on to the second class of problems: indirect links. Indirect links in a story are links to personal blogs which contain a further summary of the original article, which does not add any insights on the original story (this is a common procedure by e.g. Roland Piquepaille (don't confuse his account with that of the equally named troll!)). Instead of linking directly to TFA, these people link to their blogs, which in turn contains a link to TFA. This is annyoing because readers want to go directly to the story source, but it may not necessarily count as link spamming (at least as long as the linked to page is not a link farm). It may though be used to simply drive ad revenue to this person's blog.
What can we learn from these two problem classes:
Now this is where the rel="nofollow" enters the scene. Applying this attribute to the first class of problematic links does indeed help to extinguish the problem of link spamming. Since as of today, link spamming was mostly done through the means of the personal website link, I'd vote for adding it to that link. Links inside the article body are most of the time only of the second problem class, which cannot be mitigated by the rel="nofollow" attribute. To counter the indirect linking, only manual checking by the editors is of use.
Several comments here have brought up the question of being rewarded for submitting a story by means of increased PageRank. Some think this is legitimate, because these users have taken their time to submit a story. Others think that submitting a story should not be rewarded. This is kind of black and white thinking. I personally think that users should be rewarded for submitting a story, but not by increased PageRank, since this gives too much room for abuse. When reading the other comments here, I think that not many users are aware of the fact that submitters are indeed rewarded for story submitting, namely by gaining karma. This is a fact!
I therefore plead to add the rel="nofollow" attribute to the personal websit
Looks like ScuttleMoney^H^Hkey still doesn't get it, as well as other Slashdotters. So, let me repost this for the thousandst time.
Interesting thing is, ScuttleMonkey seems to use some standard template for * *Beatles-Beatles submissions, since ALL of them start by: "* * Beatles-Beatles writes to tell us...".
So, let me repost some earlier post of mine:
Ok, let's have a look at his george-harrison.info website. Aha, maybe the links at the bottom of the page? Yes, I see: http://george-harrison.info/reciprocal-links.html.
Sooo, what may be on that page? Quoting:
Looking at the link list (just a small excerpt):
What do we learn? * * Beatles-Beatles is an ugly link spammer who uses Slashdot to increase the PageRank of his own site, on which he hosts a link farm.
HTH!