Obviously, you don't work with kids. I used to volunteer with a youth group (10-12 years), and we had to specifically tell parents not to send cell phones. The policy was simple - confiscation for the evening, no exceptions. Some of the parents just didn't get it - how could their kids possibly be safe without their electronic leashes? So we regularly had a few cell phones in the office.
Even better. Don't delete the multiparts. Forward them to yourself. That way, legitimate emails (birthday e-card from Grandma) can still make their way to your kids, while the hard-core stuff can sit right along your own spam.
Disclaimer - I am not a parent, though I spent three years as a volunteer with 10-12 year-old kids.
They control what you get. What makes you think that everybody gets the same code? They could give different people different parts of the code (the "important" part, as well as some "identifying" code). Then, they can tell who posted it.
Most games are sold through stores. Many stores have their software neatly categorized. You want a flight sim? It's over there. First-person shooter? RPG? All in their distinct sections. They don't have a location for the new games, so it'll be tucked into a corner somewhere and won't sell. Or they may put it in a different category, where nobody (possibly including store staff) can find it.
Once you get it in the store, you need people to buy it. People "know" what they like. They don't want someone else to tell them what they want. They "know" that only game-type X is fun.
Every organization is vulnerable to social engineering. As long as at least one login requires a username and password, or you can sneak in and "convince" someone to open the door or log in for you, you can get it. Or take the time, become a mole, and get access "legitimately". It may take some time, and put you in danger, but it will work.
I don't see how that would be damaging to my "troll", as you call it. Looks like there were.5 million more men assaulted in 2001, which reinforces my point. It should not be just for women; it should be for everybody, or for nobody.
The jacket is designed for women only. Its small size and narrow armholes are intended to prevent men from using it as an offensive weapon.
It also prevents men from using it in defense. Everybody "knows" that women are alwasy being assaulted. Everybody "knows" that men are always safe. Bullshit.
Whiton conceded that women could use it offensively,
But that's OK, because they're more likely to use it defensively.
and that it would be hard for police to arrest anyone wearing one.
If this becomes more common, I can see a grounding strap being added to standard police gear. And to mugging gear.
Then there's this little tidbit from the second page.
In fact, statistics from the Department of Justice show men are more likely to be victims of violent crime than women.
When the US even thinks of doing a national id card/database there is outrage and hate and spittle against the US. Why not when GB thinks of doing this?
The majority of slashdotters seem to be American. They, along with most people, don't care about what doesn't affect them. And British ID cards affect them just as much as African hunger. Unless, of course, their in Britain or Africa;)
Some stores show both prices. CompuSmart in Victoria, BC has two prices on their labels. In small numbers is the base price. In large numbers (ie the number you're going to see), they have the after-tax price. You know exactly how much you'll pay for the product as soon as you look at it.
If it's for a company email system, make sure that the higher-ups know exactly the implications of this system. And I don't mean just the CEO. Make sure that every department head knows. Go to a meeting with them first, to discuss it. Do not enforce your own policy. That's not your job.
Make sure that people know that they can (and probably will) lose legitimate email. Make sure there's a way to bypass the filters. For example, hold the email until you can confirm the sender (reply to sender, and if your message bounces or isn't replied to in n days, delete). Let users setup their own configuration (scores, whitelists, etc), but be able to override some things (eg don't let them blacklist internal mail).
Ideally, I'd prefer something that does reject the message if it's spam
Careful. I'm assuming that these will be clients or co-workers or similar. BE CAREFUL. You do not want to drop messages. What happens if a client's email is lost because it looks like spam (refers to money, etc). Better to tag it, and let the user decide.
Are several quick checks (DCC + RBL) accurate enough and still cheaper than one slow check (Spamassassin, bayesian filtering)? does stacking of similar techniques improve accuracy significantly? (DCC + Razor, RBL + ORBS).
SpamAssassin is a stacking of checks. You can set up its config to skip those checks that you don't want to bother with. You may need to adjust scores if you do that, however.
/bin and/sbin need to be usable when only the root has been mounted. That means that they can't dynamically link to anything that's not in the root. That includes/usr/lib, which is where most dynamic linking takes place.
I don't know why they needed to be completely static, as/lib still exists, so they should be linkable with libraries in there.
It's probably just a safeguard against accidentally linking to a library in/usr/lib, just to have them fail when they're most needed.
Why do they need to change the established way things work (statically linked in/bin, dynamically linked in/usr/bin) to add a new system? Why not either adapt NSS or install it in/usr?
Slashdot Mirror
Just make sure your DVDs are licensed for public viewing (read the FBI/Interpol warning at the beginning).
Disclaimer - I am not a parent, though I spent three years as a volunteer with 10-12 year-old kids.
They control what you get. What makes you think that everybody gets the same code? They could give different people different parts of the code (the "important" part, as well as some "identifying" code). Then, they can tell who posted it.
How long will it be before the definition of a computon needs to change?
Once you get it in the store, you need people to buy it. People "know" what they like. They don't want someone else to tell them what they want. They "know" that only game-type X is fun.
Every organization is vulnerable to social engineering. As long as at least one login requires a username and password, or you can sneak in and "convince" someone to open the door or log in for you, you can get it. Or take the time, become a mole, and get access "legitimately". It may take some time, and put you in danger, but it will work.
-1, Groaner
Ask for invalid names. If it accepts those, then blacklist it.
I don't see how that would be damaging to my "troll", as you call it. Looks like there were .5 million more men assaulted in 2001, which reinforces my point. It should not be just for women; it should be for everybody, or for nobody.
Then there's this little tidbit from the second page.
Look - they have a graph of hits over time at the bottom. Let's see how well that thing scales ;)
Some stores show both prices. CompuSmart in Victoria, BC has two prices on their labels. In small numbers is the base price. In large numbers (ie the number you're going to see), they have the after-tax price. You know exactly how much you'll pay for the product as soon as you look at it.
Make sure that people know that they can (and probably will) lose legitimate email. Make sure there's a way to bypass the filters. For example, hold the email until you can confirm the sender (reply to sender, and if your message bounces or isn't replied to in n days, delete). Let users setup their own configuration (scores, whitelists, etc), but be able to override some things (eg don't let them blacklist internal mail).
I don't know why they needed to be completely static, as /lib still exists, so they should be linkable with libraries in there.
It's probably just a safeguard against accidentally linking to a library in /usr/lib, just to have them fail when they're most needed.
Why do they need to change the established way things work (statically linked in /bin, dynamically linked in /usr/bin) to add a new system? Why not either adapt NSS or install it in /usr?
But at least they're admitting it this time ;)
This is exactly what I said before, except that I used Google instead of AltaVista.