That's absurd, and demonstrates that you don't understand how Unix permissions work. The owner of a file can change the group of any file they own (to any group they are a member of, on most versions of Unix), and whether or not other users can access the file based on group ownership or everyone else. The owner of the file has a great deal of flexibility in deciding how to provide selective access to its files.
This is the problem... people who insist that ACLs are necessary either don't completely understand Unix permissions, or refuse to spend time thinking about how to solve their problem with Unix permissions. I have been a Unix System administrator for 5 years, and a syadmin of other OSes for longer than that, in a variety of environments, including several with Windows integrated into the environtment, and I have NEVER encountered a problem I couldn't solve with Unix permissions (except for one application which was ported from DOS without any regard for access control -- but here the problem is the poor design of the application, NOT Unix permissions).
A few people raised some interesting points (like appending to log files) but Unix has already proven that there are other ways to solve those problems without ACLs (like using syslog for logging, which if set up properly allows anyone to add log entries, but only the superuser to remove them).
While ACLs might have some valid uses, those applications can generally all be implemented in other ways without ACLs, especially now that the Linux kernel has capabilities (which people keep overlooking). The problem is NOT that Unix permissions are inadequate, but that people refuse to THINK about the problem they are trying to solve. ACLs are most often a cop-out for lazy system administrators. As others have pointed out, they are clunky, error prone, and complicated to administer. They leave too many opportunities for sloppy administrators to create endless streams of access lists which, in the end, no one understands, and which no one can clean up, because in so trying they will break the application they are trying to fix.
Oh, and someone is bound to point out that Unix has security holes that can allow non-priviledged users to become root and (for example) remove log entries we were trying to protect in the previous example. That may be true, but virtually ALL operating systems have such problems, including those that have ACLs like Windows NT. All OSes in common usage have weaknesses that can be exploited. Informed system administrators CAN make efforts to plug up those holes, drastically reducing the risks. This is, after all, the point of having a system administrator. If your sysadmin sucks, get a new one. But you still don't need ACLs.
And for this, Linux has capabilities. It is already possible to run Linux without a root user, except that the userland code to do so has not been written. Please see Alan Cox's posts on LKML about this topic.
Please moderate this back down. The poster obviously does not understand Unix permissions. It is NOT security through obscurity.
If you do not have access to a directory (i.e. the read and execute permissions for whatever user class you fall into -- probably "other" -- are TURNED off), YOU CAN NOT READ THE FILES IN IT. PERIOD.
In the real world, in most cases, going through the trouble I describe is not necessary. It is only necessary in a (usually) small number of cases where there are two distinct groups of people that require two different types of access.
In the University example that you describe, it is unlikely that all of these classes will have people working in teams for every assignment. In many such courses, the students' work is entirely individual.
In those cases where it is not, you simply need to create a Unix group for each team. All of the files for that team's project are kept in a central project-related directory. There is no reason whatsoever for any user not in that group to have access of any kind to the files of that group's project, so a more complicated scheme is not necessary.
Moreover, the classes offered from semester to semester don't tend to change much, so for the most part the groups will stay the same too, so you're not likely to need to spend a lot of time maintaining that, nor are you likely to run out of groups, even in a much larger CS department.
In the "real world", your first case just isn't really a problem. I learned how to use Unix permissions from the sysadmin of my college, whose CS department has over a thousand users, who successfully employed this tecnique for years.
The second case, modify vs. append: To me the latter is just a special case of the former. I personally see no reason why one should be treated differently from the other. If you have a compelling reason why someone should be allowed to append data to a file, but not modify the data that's already in the file, I'd certainly like to hear it.
Your permission to stat a file is controlled by whether or not you have read access to the directory the file is in. What legitimate reason can you suggest for preventing a user from seeing SOME files in a directory they legitimately have access to, but not others? What practical purpose does this serve?
The last case just doesn't seem very convincing to me at all. There are few practical arguments for limiting, to use your example, times that people can play games on a given system.
If you don't want the games eating up server CPU cycles, don't put them on the server! Students have no "off-hours" to speak of; they tend to work all throughout the night when a project is due.
So in order to be fair to everyone, there shouldn't be time limits.
If you're concerned about IRC or tank battle using up your network bandwitdh, don't bother, because the students can easily consume much more bandwidth from the PC in their dorm room, and probably are already.
In a non-university environment, most of these just aren't issues. There will be a limit to the number of projects your company is working on via a given fileserver. People have their own workstations (or PCs) to play games on, so you don't need to worry about when they are doing that. If you're going to let them play games at all, they're certainly not going to prevent another user from getting their job done due to resource starvation.
I'm not saying there's no value to having some of these features. But I do fail to see a compelling NEED. Also, capabilities addresses some of the things you're looking for, further suggesting that ACLs are not necessary.
Small correction: The SGID bit controls only the group ownership. The access modes will be set according to the creator's UMASK value. Either the owner or the superuser must be responsible for ensuring that the permissions of newly created files are correct.
There are two basic access needs that people need to have to data: the ability to READ the data, and the ability to MODIFY the data. In ALL cases (at least, in all useful cases), these priviledges can be granted using standard Unix permissions.
Let's say you have a directory full of files, and you need some people to be able to write to these files (which implies they'll also need to be able to read the files, to verify their changes), and you have another group of people who needs to be able to read the files. Everyone else in the organization should have NO access. This is the most complicated case.
Can this be done with standard Unix permissons? At first glance, you might think that you can't, because the only permissions provided in Unix are User (owner), Group, and Other (world). You can't control the access for a second group, which is what you need, right?
However, the answer is YES! You can do this. Here's how:
Create one group each for the people who need to be able to read the files, and write the files. For simplicity of the example, let's call the groups "read" and "write" respectively.
Now, add every user who needs read access to those files to the "read" group, and add all users who need write access to BOTH groups.
Now, create a top level directory, like this (only ownerships, permissions, and the name are shown for brevity):
Both groups we created can cd into this directory (because we added the "write" group to the "read" group, remember?). Now, under that directory, create one or more directories where your data will be stored, like this:
The '2' sets the SGID bit on the directory, which forces all files created in this directory to be created group-owned by the "write" group (it copies the group ownership of the directory to all new files in it). It will also make new files created in this directory group writable by default (again, copying the group permissions from the directory).
You might also want to prevent users from deleting files they don't own, by setting the sticky bit on the directory, which will make the '2' a '3' instead.
Now, users in the "write" group can create and write to files in this directory, and users in the "read" group will be able to read them, because they will be readable by other (world). However, everyone else will NOT be able to read them, because in order to do so, they would have needed to be in the "read" group in order to cd into topdir to get to datadir (which is why we also included the users in the "write" group in the "read" group)!
Thus, your problem is solved. Do this for every directory where the groups of people who need each type of access are different. This is BETTER than ACLs because a) it is either the same amount of administrative effort than managing ACL's on a per-directory basis (but you manage group membership instead), or LESS administrative effort than managing ACLs on a per-file basis; and b) it FORCES you to organize your data heirarchically by who has access to it.
Get over ACLs... they are a waste of time and programming effort.
You could argue that you might want some third group of people to have write access ONLY, but the practical value of this is very limited. If you feel that you need this you are probably being silly or WAY too paranoid, even for a system administrator. Limiting people from reading data that they can over-write is generally nonsensical.
I don't deny that there are certain very narrow applications for that sort of access limitation, but the likelihood that such an application would also present the need to have groups with each of those access requirements (read, read/write, and write-only) seems rather slim.
Note to slashdot maintainers: PLEASE make the damn text box for typing comments into bigger! The one currently provided on the web form makes typing long comments especially painful. And allowing the CODE HTML tag would be nice too.
The Empress was played by Thora Birch, who also played Jane in American Beauty. I wouldn't call her the greatest actress in the history of the motion picture industry, but she's not all that bad. The script left much to be desired, but then it wasn't ever meant to be a movie classic. It's an action film, with an action plot and an action script, and with lots of nice action special effects. Those dragons were awesome, as Dragons should be. It could have been better, but it did what it meant to do. Check out the OSS linux clustering technology called
Welcome to this planet. I take it you are not familiar with humans?
There are still people who do things just to help people, but you're right; there aren't nearly enough of them.People in this country have become overwhelmed by their own avarice. It's disgusting. Stop the f*cking planet, I want to get off. No joke.
Check out the OSS linux clustering technology called
No incentive? How about because I want to live? And I want my family to live? And I want my friends to live?
Isn't that incentive enough?
Besides, if your drug is sound, and actually cures or prevents diseases (or even if it doesn't and you advertise as much as Claritin does), people will buy your drugs... Patents don't enter into it. Check out the OSS linux clustering technology called
Sure but what I'm saying is that there need not be anything different about an antipatent and a patent. If you want to protect an invention, the standard legal way to do that is to apply for a patent. You can potentially do various other things to prove prior art or whatever, but in court the most protections will be afforded to those inventions that have registered patents.
Now, you can make the argument that you have to pay for a patent, and some inventors may not have the money for the neccessary fees to deal with the application. But if that's the case, then it's not terribly likely they'll have the money required to fight a court battle over a patent dispute (brought on by an actual patent "owner") either, so they'll probably just end up losing their rights anyway, and the whole point is moot.
Check out the OSS linux clustering technology called
Just as the GPL uses existing copyright law, these "Antipatents" are nothing more than patents for which the owner does not enforce their rights. You don't need to do anything special to protect your rights, other than apply for a patent, much as anyone else with an invention does.
Besides which, the concept seems a little silly. When you have an invention, being a device and not code, you have the end product for which there is no real "source" so to speak, so there is no need to open-source it. If you want to duplicate a patented device (evading the subject of whether or not it's legal to do so), just look at it, and copy it. Check out the OSS linux clustering technology called
C'mon guys, you missed the glaring error of "Copywites?"
I enjoy reading Slashdot to get my daily dose of geek news, but have long desired to see some time spent on cleaning up the articles that get posted.
I can see why you might not want to meddle with the comments of the people who submit the story, as editing what's posted could make you liable for what they say, but at least run your own comments through a spell-checker! And actually, haven't you already assumed liablity for posted stories by deciding what gets posted and what doesn't?
Despite the fact that it is a great place to get the majority of news that I'm most interested in, in my opinion, Slashdot is about one rung on the ladder below being a respectable journalistic endeavor. The two main factors keeping it from such are that:
Very little original content appears here. Most of the stories that appear here are stolen from other news sites.
The spelling and grammar that appears in a lot of the stories is simply attrocious.
The first isn't necessarily a bad thing, since Slashdot still (obviously) serves a useful purpose: pooling together all of the notable news of interest to a particular group. O.k., they often reject stories that might be interesting or noteworthy -- I still haven't figured out what sort of criteria these guys use to decide what gets posted and what doesn't. But that's beside the point.
The second one though, while not ultimately damning, does take away from the reader's experience of reading news at Slashdot. I'd really like to see the stories get cleaned up.
Bottom line: Slashdot needs an editor that can read and write English. Please get one!
Check out the OSS linux clustering technology called
No it doesn't; at the very least having the information available gives you some historical insight as to where we were medically at any given point in time.
But the issues are much more serious than that... The DMCA is a very large step in the wrong direction for your freedoms in this country, and this is just another example of how the DMCA is going to strip you and all of us of our Constitutional freedoms if we don't wake up and DO something about it.
This country is becoming it's own worst nightmare; an Orwellian police state. Just look at the DVD lawsuit. People are being prevented from linking to sites because of the content that's there... is that NOT a violation of your Constitutional right to free speech? This particular article is somewhat remenicent of Farrenheit 451, where books were illegalized and burned in the street. Is this the kind of society you want to live in?
There is a war brewing... a war between the techological haves and have-nots. The people who have the information don't want YOU to get it, so they can monopolize their possesion of it and make money from it. That's what this is all about.
What's amazing to me is that we, the geek community, have done very little about this. The work that we do is being criminalized, rather than cherished as it should be. Reverse engineering, the act of figuring out how things work, is all but illegal, now that we have the DMCA. Freedom of speech is diminished, because you can't describe how something works if the creator made some half-assed electronic attempt to maintain control over it, thanks to the DMCA.
Why have we been so quiet about this? Write your congressman and let them know what an abomination you think the DMCA is. Visit the EFF's website and find out what you can about how the government is allowing big business to strip you of your Constitutionally "guaranteed" civil rights.
And when you finally get it, tell your friends.
Check out the OSS linux clustering technology called
Heehee... I was going to say "High-Availability Clustering solution" but opted for "product" instead, so as not to give anyone BINGO! (as in, buzzword bingo)
=8^)
-Captain Carnage
(and yeah, I work for Mission Critical Linux)
-- Check out the OSS linux clustering technology called
Earlier this week Mission Critical Linux open-sourced their High-availability cluster technology called Kimberlite. I've seen this on lwn and linuxtoday, but it was notably absent from slashdot.
From what I've seen, it's better than LVS and Pirhanna because it gives you higher levels of data integrity. For example, when a node hangs, but doesn't die, the other node kills it, so that the first can't recover and suddenly you have 2 nodes serving inconsistent data. It also works with shared SCSI storage between two nodes, which I don't think the others do....
If you're interested in High Availability computing, this is definitely worth checking out. The kimberlite homepage is at http://oss.missioncriticallinux.com on your radio dial...:)
Check out the OSS linux clustering technology called
admit "hacking" is cool but when it becomes malicious or starts breaking the laws its time to pull the plug. Granted there will always be "bad" hackers so we need to train "good" hackers to fight off the bad.
Um, huh? Did you read the article? If you did, you'd know that the term "hacking" was not used in the sense of "system cracker" but in the sense of "creative solution to a problem." In that context, your comment makes absolutely no sense whatsoever.
I didn't read the article, but the problem is that in probably most cases hackers don't have enough shares for their vote to matter. The only way it would make a difference is if they went to the board meeting and were very vocal.
And for god's sake people, stop posting "1st post" comments and get a life!
Not to be a party-pooper, I've participated in discussions like this before after all, but the correct answer to the question, and the only one that should be offered, is GO SEEK THE ADVICE OF A LAWYER.
There are lots of people out there that are educated or semi-educated in the ways of the law, but you shouldn't really take the word of lay people on something like this, which could potentially land you in a lot of heat.
Hell, there are trained professionals out there who can't get it right, so why would anyone want to risk listening to this bunch. So go talk to someone who is a paid professional, and hope they know what they're doing.
Complain to your management or whoever manages the filtering software. L0pht is not a criminal organization (though some of their practices are controvercial). They are a legitimate security consulting organization, and they give back to the security community whenever they find vulnerabilities.
If your management doesn't want secure systems, they should continue to filter out those web sites. But I suspect if you let them know the value of the service they provide.
People in general have a tendency to villify anything they don't understand, especially when it gives people a kind of power they don't have. This is exactly what is going on with the field of computer security. To make matters worse, there is a double standard... Law enforcement and government agencies openly condemn the actions of legitimate hackers, and then turn around and hire them to do their dirty work.
Slashdot Mirror
That's absurd, and demonstrates that you don't understand how Unix permissions work. The owner of a file can change the group of any file they own (to any group they are a member of, on most versions of Unix), and whether or not other users can access the file based on group ownership or everyone else. The owner of the file has a great deal of flexibility in deciding how to provide selective access to its files.
This is the problem... people who insist that ACLs are necessary either don't completely understand Unix permissions, or refuse to spend time thinking about how to solve their problem with Unix permissions. I have been a Unix System administrator for 5 years, and a syadmin of other OSes for longer than that, in a variety of environments, including several with Windows integrated into the environtment, and I have NEVER encountered a problem I couldn't solve with Unix permissions (except for one application which was ported from DOS without any regard for access control -- but here the problem is the poor design of the application, NOT Unix permissions).
A few people raised some interesting points (like appending to log files) but Unix has already proven that there are other ways to solve those problems without ACLs (like using syslog for logging, which if set up properly allows anyone to add log entries, but only the superuser to remove them).
While ACLs might have some valid uses, those applications can generally all be implemented in other ways without ACLs, especially now that the Linux kernel has capabilities (which people keep overlooking). The problem is NOT that Unix permissions are inadequate, but that people refuse to THINK about the problem they are trying to solve. ACLs are most often a cop-out for lazy system administrators. As others have pointed out, they are clunky, error prone, and complicated to administer. They leave too many opportunities for sloppy administrators to create endless streams of access lists which, in the end, no one understands, and which no one can clean up, because in so trying they will break the application they are trying to fix.
Oh, and someone is bound to point out that Unix has security holes that can allow non-priviledged users to become root and (for example) remove log entries we were trying to protect in the previous example. That may be true, but virtually ALL operating systems have such problems, including those that have ACLs like Windows NT. All OSes in common usage have weaknesses that can be exploited. Informed system administrators CAN make efforts to plug up those holes, drastically reducing the risks. This is, after all, the point of having a system administrator. If your sysadmin sucks, get a new one. But you still don't need ACLs.
agreed.
And for this, Linux has capabilities. It is already possible to run Linux without a root user, except that the userland code to do so has not been written. Please see Alan Cox's posts on LKML about this topic.
Please moderate this back down. The poster obviously does not understand Unix permissions. It is NOT security through obscurity.
If you do not have access to a directory (i.e. the read and execute permissions for whatever user class you fall into -- probably "other" -- are TURNED off), YOU CAN NOT READ THE FILES IN IT. PERIOD.
Sorry, but WHO NEEDS ACCESS TO A FILE IS A FUNCTION OF WHAT THE PURPOSE OF THE DATA IS!
The two are interlinked.
If you have a programmer working on more than 15 projects at a time, HE'S REALLY OVERWORKED!
In the real world, in most cases, going through the trouble I describe is not necessary. It is only necessary in a (usually) small number of cases where there are two distinct groups of people that require two different types of access.
In the University example that you describe, it is unlikely that all of these classes will have people working in teams for every assignment. In many such courses, the students' work is entirely individual.
In those cases where it is not, you simply need to create a Unix group for each team. All of the files for that team's project are kept in a central project-related directory. There is no reason whatsoever for any user not in that group to have access of any kind to the files of that group's project, so a more complicated scheme is not necessary.
Moreover, the classes offered from semester to semester don't tend to change much, so for the most part the groups will stay the same too, so you're not likely to need to spend a lot of time maintaining that, nor are you likely to run out of groups, even in a much larger CS department.
In the "real world", your first case just isn't really a problem. I learned how to use Unix permissions from the sysadmin of my college, whose CS department has over a thousand users, who successfully employed this tecnique for years.
The second case, modify vs. append: To me the latter is just a special case of the former. I personally see no reason why one should be treated differently from the other. If you have a compelling reason why someone should be allowed to append data to a file, but not modify the data that's already in the file, I'd certainly like to hear it.
Your permission to stat a file is controlled by whether or not you have read access to the directory the file is in. What legitimate reason can you suggest for preventing a user from seeing SOME files in a directory they legitimately have access to, but not others? What practical purpose does this serve?
The last case just doesn't seem very convincing to me at all. There are few practical arguments for limiting, to use your example, times that people can play games on a given system.
If you don't want the games eating up server CPU cycles, don't put them on the server! Students have no "off-hours" to speak of; they tend to work all throughout the night when a project is due.
So in order to be fair to everyone, there shouldn't be time limits.
If you're concerned about IRC or tank battle using up your network bandwitdh, don't bother, because the students can easily consume much more bandwidth from the PC in their dorm room, and probably are already.
In a non-university environment, most of these just aren't issues. There will be a limit to the number of projects your company is working on via a given fileserver. People have their own workstations (or PCs) to play games on, so you don't need to worry about when they are doing that. If you're going to let them play games at all, they're certainly not going to prevent another user from getting their job done due to resource starvation.
I'm not saying there's no value to having some of these features. But I do fail to see a compelling NEED. Also, capabilities addresses some of the things you're looking for, further suggesting that ACLs are not necessary.
Small correction: The SGID bit controls only the group ownership. The access modes will be set according to the creator's UMASK value. Either the owner or the superuser must be responsible for ensuring that the permissions of newly created files are correct.
Let's say you have a directory full of files, and you need some people to be able to write to these files (which implies they'll also need to be able to read the files, to verify their changes), and you have another group of people who needs to be able to read the files. Everyone else in the organization should have NO access. This is the most complicated case.
Can this be done with standard Unix permissons? At first glance, you might think that you can't, because the only permissions provided in Unix are User (owner), Group, and Other (world). You can't control the access for a second group, which is what you need, right?
However, the answer is YES! You can do this. Here's how:
Create one group each for the people who need to be able to read the files, and write the files. For simplicity of the example, let's call the groups "read" and "write" respectively.
Now, add every user who needs read access to those files to the "read" group, and add all users who need write access to BOTH groups.
Now, create a top level directory, like this (only ownerships, permissions, and the name are shown for brevity):
drwxr-x--- root read topdir
# mkdir topdir
# chgrp read topdir
# chmod 750 topdir
Both groups we created can cd into this directory (because we added the "write" group to the "read" group, remember?). Now, under that directory, create one or more directories where your data will be stored, like this:
drwxrwsr-x root write datadir
# cd topdir
# mkdir datadir
# chgrp write datadir
# chmod 2775 datadir
The '2' sets the SGID bit on the directory, which forces all files created in this directory to be created group-owned by the "write" group (it copies the group ownership of the directory to all new files in it). It will also make new files created in this directory group writable by default (again, copying the group permissions from the directory).
You might also want to prevent users from deleting files they don't own, by setting the sticky bit on the directory, which will make the '2' a '3' instead.
Now, users in the "write" group can create and write to files in this directory, and users in the "read" group will be able to read them, because they will be readable by other (world). However, everyone else will NOT be able to read them, because in order to do so, they would have needed to be in the "read" group in order to cd into topdir to get to datadir (which is why we also included the users in the "write" group in the "read" group)!
Thus, your problem is solved. Do this for every directory where the groups of people who need each type of access are different. This is BETTER than ACLs because a) it is either the same amount of administrative effort than managing ACL's on a per-directory basis (but you manage group membership instead), or LESS administrative effort than managing ACLs on a per-file basis; and b) it FORCES you to organize your data heirarchically by who has access to it.
Get over ACLs... they are a waste of time and programming effort.
You could argue that you might want some third group of people to have write access ONLY, but the practical value of this is very limited. If you feel that you need this you are probably being silly or WAY too paranoid, even for a system administrator. Limiting people from reading data that they can over-write is generally nonsensical.
I don't deny that there are certain very narrow applications for that sort of access limitation, but the likelihood that such an application would also present the need to have groups with each of those access requirements (read, read/write, and write-only) seems rather slim.
Note to slashdot maintainers: PLEASE make the damn text box for typing comments into bigger! The one currently provided on the web form makes typing long comments especially painful. And allowing the CODE HTML tag would be nice too.
And maybe you didn't know that Alpha was made by DEC, before Compaq bought them? Comaq had nothing to do with the quality of Alphas.
The Empress was played by Thora Birch, who also played Jane in American Beauty. I wouldn't call her the greatest actress in the history of the motion picture industry, but she's not all that bad. The script left much to be desired, but then it wasn't ever meant to be a movie classic. It's an action film, with an action plot and an action script, and with lots of nice action special effects. Those dragons were awesome, as Dragons should be. It could have been better, but it did what it meant to do.
Check out the OSS linux clustering technology called
There are still people who do things just to help people, but you're right; there aren't nearly enough of them.People in this country have become overwhelmed by their own avarice. It's disgusting. Stop the f*cking planet, I want to get off. No joke.
Check out the OSS linux clustering technology called
Isn't that incentive enough?
Besides, if your drug is sound, and actually cures or prevents diseases (or even if it doesn't and you advertise as much as Claritin does), people will buy your drugs... Patents don't enter into it.
Check out the OSS linux clustering technology called
Now, you can make the argument that you have to pay for a patent, and some inventors may not have the money for the neccessary fees to deal with the application. But if that's the case, then it's not terribly likely they'll have the money required to fight a court battle over a patent dispute (brought on by an actual patent "owner") either, so they'll probably just end up losing their rights anyway, and the whole point is moot.
Check out the OSS linux clustering technology called
Just as the GPL uses existing copyright law, these "Antipatents" are nothing more than patents for which the owner does not enforce their rights. You don't need to do anything special to protect your rights, other than apply for a patent, much as anyone else with an invention does.
Besides which, the concept seems a little silly. When you have an invention, being a device and not code, you have the end product for which there is no real "source" so to speak, so there is no need to open-source it. If you want to duplicate a patented device (evading the subject of whether or not it's legal to do so), just look at it, and copy it.
Check out the OSS linux clustering technology called
I enjoy reading Slashdot to get my daily dose of geek news, but have long desired to see some time spent on cleaning up the articles that get posted. I can see why you might not want to meddle with the comments of the people who submit the story, as editing what's posted could make you liable for what they say, but at least run your own comments through a spell-checker! And actually, haven't you already assumed liablity for posted stories by deciding what gets posted and what doesn't?
Despite the fact that it is a great place to get the majority of news that I'm most interested in, in my opinion, Slashdot is about one rung on the ladder below being a respectable journalistic endeavor. The two main factors keeping it from such are that:
- Very little original content appears here. Most of the stories that appear here are stolen from other news sites.
- The spelling and grammar that appears in a lot of the stories is simply attrocious.
The first isn't necessarily a bad thing, since Slashdot still (obviously) serves a useful purpose: pooling together all of the notable news of interest to a particular group. O.k., they often reject stories that might be interesting or noteworthy -- I still haven't figured out what sort of criteria these guys use to decide what gets posted and what doesn't. But that's beside the point.The second one though, while not ultimately damning, does take away from the reader's experience of reading news at Slashdot. I'd really like to see the stories get cleaned up.
Bottom line: Slashdot needs an editor that can read and write English. Please get one!
Check out the OSS linux clustering technology called
No it doesn't; at the very least having the information available gives you some historical insight as to where we were medically at any given point in time.
But the issues are much more serious than that... The DMCA is a very large step in the wrong direction for your freedoms in this country, and this is just another example of how the DMCA is going to strip you and all of us of our Constitutional freedoms if we don't wake up and DO something about it.
This country is becoming it's own worst nightmare; an Orwellian police state. Just look at the DVD lawsuit. People are being prevented from linking to sites because of the content that's there... is that NOT a violation of your Constitutional right to free speech? This particular article is somewhat remenicent of Farrenheit 451, where books were illegalized and burned in the street. Is this the kind of society you want to live in?
There is a war brewing... a war between the techological haves and have-nots. The people who have the information don't want YOU to get it, so they can monopolize their possesion of it and make money from it. That's what this is all about.
What's amazing to me is that we, the geek community, have done very little about this. The work that we do is being criminalized, rather than cherished as it should be. Reverse engineering, the act of figuring out how things work, is all but illegal, now that we have the DMCA. Freedom of speech is diminished, because you can't describe how something works if the creator made some half-assed electronic attempt to maintain control over it, thanks to the DMCA.
Why have we been so quiet about this? Write your congressman and let them know what an abomination you think the DMCA is. Visit the EFF's website and find out what you can about how the government is allowing big business to strip you of your Constitutionally "guaranteed" civil rights.
And when you finally get it, tell your friends.
Check out the OSS linux clustering technology called
Heehee... I was going to say "High-Availability Clustering solution" but opted for "product" instead, so as not to give anyone BINGO! (as in, buzzword bingo)
=8^)
-Captain Carnage
(and yeah, I work for Mission Critical Linux)
--
Check out the OSS linux clustering technology called
Well where the hell was that? Inquiring male geeks wanna know... :)
Check out the OSS linux clustering technology called
Earlier this week Mission Critical Linux open-sourced their High-availability cluster technology called Kimberlite. I've seen this on lwn and linuxtoday, but it was notably absent from slashdot.
:)
From what I've seen, it's better than LVS and Pirhanna because it gives you higher levels of data integrity. For example, when a node hangs, but doesn't die, the other node kills it, so that the first can't recover and suddenly you have 2 nodes serving inconsistent data. It also works with shared SCSI storage between two nodes, which I don't think the others do....
If you're interested in High Availability computing, this is definitely worth checking out. The kimberlite homepage is at http://oss.missioncriticallinux.com on your radio dial...
Check out the OSS linux clustering technology called
When I go to the shockwave site, using Linux and Netscape 4.72 with java and javascript turned on, I get a javascript error.
When I go there with java and javascript turned off, I get nothing. Just a blank, grey page.
Linux
-----
admit "hacking" is cool but when it becomes malicious or starts breaking the laws its time to pull the plug. Granted there will always be "bad" hackers so we need to train "good" hackers to fight off the bad.
Um, huh? Did you read the article? If you did, you'd know that the term "hacking" was not used in the sense of "system cracker" but in the sense of "creative solution to a problem." In that context, your comment makes absolutely no sense whatsoever.
Plus you would have to have voting stock... most common shares are non-voting these days.
I didn't read the article, but the problem is that in probably most cases hackers don't have enough shares for their vote to matter. The only way it would make a difference is if they went to the board meeting and were very vocal.
And for god's sake people, stop posting "1st post" comments and get a life!
Not to be a party-pooper, I've participated in discussions like this before after all, but the correct answer to the question, and the only one that should be offered, is GO SEEK THE ADVICE OF A LAWYER.
There are lots of people out there that are educated or semi-educated in the ways of the law, but you shouldn't really take the word of lay people on something like this, which could potentially land you in a lot of heat.
Hell, there are trained professionals out there who can't get it right, so why would anyone want to risk listening to this bunch. So go talk to someone who is a paid professional, and hope they know what they're doing.
Complain to your management or whoever manages the filtering software. L0pht is not a criminal organization (though some of their practices are controvercial). They are a legitimate security consulting organization, and they give back to the security community whenever they find vulnerabilities.
If your management doesn't want secure systems, they should continue to filter out those web sites. But I suspect if you let them know the value of the service they provide.
People in general have a tendency to villify anything they don't understand, especially when it gives people a kind of power they don't have. This is exactly what is going on with the field of computer security. To make matters worse, there is a double standard... Law enforcement and government agencies openly condemn the actions of legitimate hackers, and then turn around and hire them to do their dirty work.