Where do you source your guaranteed bug-free software ?
The whole piece of software isn't bug free. The only thing I'm concerned about is the auth system (generally a relatively small, simple piece of code) being bug free.
It's not an issue if your FTP server has an exploit based on LISTing files if it correctly ignores all input until a valid password is entered, and its handling of that password does not have bugs.
So a firewall is justifiable because knowledgable admins of a managed network "may not have good control over who is connecting to their network", but with novice users sitting directly on the internet at large with no control whatsoever who is connecting to their computers it isn't ?
As I said, these are different types of firewalls -- personal versus traditional.
I'll grant that some sort of system to deal with the fact that some systems ship out-of-box in an awful state would be a good idea. However, all one needs is a piece of software that disables all the extraneous servers running on, say, Windows. Adding a firewall just adds complexity and provides no security benefit above disabling said servers.
First, this is nothing more than an authentication system. It's designed to allow a server to authenticate itself as a trusted source for a domain's email. However, the designers chose to use DNS as a transport mechanism. Not a good idea. DNS is designed to be lightweight and low latency, not to be secure. It's pretty easy to spoof DNS responses. Plus, DNS data tends to get cached. All you need to do is spoof a response, the nameserver's cache is poisoned with false data, and the next N emails (until the cached data expires) are accepted as valid.
Second, this system relies on having everyone implement such functionality. Spammers don't give a damn about return addresses, so they can send email with a from address at any domain. The annoying and ineffective attempts at stopping all open mail relays on the Internet illustrate the failure of this model. A security system that relies on correct implementation over the full Internet to function properly will not work in real life.
Third, this fails to deal with throwaway domains. The authors waffle a bit about them, and finally come out and admit that more mechanisms are required. Dammit, if we had a good PKI trust-ranking system (which is the sort of thing that they are requiring to fix their failings) we wouldn't need this system at *all*, since we could simply sign email and have trust rankings for users.
Enough about the bad design: other reasons I don't like it include:
* The authors have made a decision to make it really annoying to send email from a machine, and have to work with your ISP just to have a mail server. There are plenty of more solid antispam proposed mechanisms that do not place restrictions on who runs what servers (pay-per-email or pay-per-initial-email, PKI systems). This is much more in line with the way the Internet works for most services.
* There is a supposedly trusted authentication system being spread across the entire Internet over an insecure transport protocol.
* DNS caching can make moving an SMTP server or setting up a new one take a significant amount of time.
* IP-based auth isn't a great idea anyway, for a number of reasons. The authors claim that it isn't a huge issue, because IP spoofing is harder (I disagree -- things like Mobile IP have made it harder to *block* IP spoofing).
* Users have no control over what gets blocked. If I *want* to receive email of a particular type, I can't. Two ISPs (sending and receiving) are the ones that determine what mail I can receive). This is perhaps acceptable within a company, but annoying and goes against traditional Internet structure.
* It does nothing to avoid compromised end user machines.
* It does nothing to deal with throwaway accounts.
* It does nothing to deal with misconfigured servers.
No, it's a sign that you are a realist. Whatever patches you download for windows, theres still the RPC ports open, and when know the trouble they've caused recently.
No. Most Microsoft server software is broken WRT to security and should not be used. RPC should not be active.
In addition to this, what if the user opens an attachment that just happens to be a trojan that captures their every key-stroke (including their personal banking passwords and/or credit card no's), connects to the internet and sends this information to the nefarious script kiddie who mailed it out.
Sounds nice, but it's a lost cause. There are zillions of ways to slip past "trojan catchers". One big hole is MSIE -- all you have to do is convince it (in one of many ways) to contact an outside system.
Sorry, but that's absolute bullshit. Operating systems are inherently complex pieces of software that will (despite developers best efforts) contain security vulnerabilities somewhere.
I'm not talking about operating systems (other than the networking stack). I'm talking about remote vulnerabilities. You should not be running flawed servers. The only thing a server should let a remote user do is try to authenticate (and yes, auth code should be well-reviewed code).
Ocaml has been developed. If you can stand programming in functional languages, you already have a fast language suitable for application programming.
The problem with languages recently is that they aren't driven by CS people, but by businesspeople. Java was not enthusiastically endorsed by language people, but by business technology folks.
He just said that he didn't have enough evidence to issue a preliminary injunction.
The only time these should be issued is if there is immediate, severe, and irrevocable harm being caused by an action, and the judge feels that the harm-causer is unlikely to win their court case.
I'd say this is pretty reasonable. The idea is to keep law from becoming someone's subjective opinion -- the court is where the real arguments will be heard. Preliminary injunctions are emergency actions, not to be taken in every case.
Since not having a firewall opens you to many other abuses than just Messenger popups, better advice to affected users might be to get the free Kerio Personal Firewall, or another firewall product.
Getting a firewall and not disabling the Messenger Service also allows the several other Windows services that use Messenger for reporting to the end-user to continue to make those reports.
I can't agree.
I've found the "personal firewall" to be one of the biggest disasters in recent memory. It has essentially no utility to almost any users.
It tends to get users worried about attacks that they could otherwise just ignore.
They may have bugs themselves or impact performance.
They cost money.
Requiring a firewall is *always* a sign that you are either using broken software or you have misconfigured your software. Messenger is decidedly broken. It has a completely broken authentication model.
In a normal system, any servers you have running should (a) support authentication and (b) not allow remote attacks inward. I never use firewalls for my small networks, because it's entirely unnecessary. If I manage to mask a security problem by slapping up a firewall, all that means is that I now have a security vulnerability that can be exploited if someone manages to get inside my network. I should secure my systems properly.
(Note that non-personal firewalls *do* have a legitimate use -- IT may not have good control over who is connecting what to their network, and furthermore, the additional time that a network-wide firewall may give when a worm outbreak comes along may be enough time to finish testing and deploying a patch).
I do not use firewalls on any of the systems I run. There is no reason to do so if the system is properly configured.
* Familiarity. Just as most people aren't willing to learn a new (possibly significantly superior) control interface to their car, most people don't want to relearn an interface to their computer.
* Software availability. Lots of custom and vertical-market software and games are only available for Windows.
* Lock-in. Microsoft is actively making it unpleasant to switch from their software.
From a security standpoint, this is a dumb idea. Really dumb. It's stupid, open to a ton of attacks, and does diddly about spam. However, it's probably going to get some popularity for the following reasons:
* Folks hate spam, and will glom onto anything that claims to reduce it with the gullibility of a cancer victim being scammed by a faith healer.
* It's easy for IT folks to implement. The CIO can say that he "implemented an initiative to reduce the most frequent user complaint, saving the company N dollars". He doesn't give a damn about whether he actually *accomplishes* anything, just whether it looks good.
* SPF is a pet project of someone. Obviously not someone who's a security person, but someone.
* There's money in it for consultants. The firewall craze made many many people very much money. The promise of a *new* even less useful system that can be used to pry money from companies is quite appealing.
Things that *could* reasonably be done to combat spam:
* Limit email amplification.
* Require one of a number of pay or auth systems for email.
* Whitelisting
* Allowing clients to publish rules to mail servers (so that a client whitelist, for instance, would allow a server to avoid soaking up any bandwidth at all...this would be a useful set of IMAP extensions).
Frankly, unless a bunch of engineers get together and put out a *useful* RFC (i.e. not this crap) a la PNG, there's probably going to be an industry consortium that decides what to do. And standards committes have an awfully low rate of getting-it-right.
Blind, stupid fanaticism doesn't do anything to help Apple -- it just means that people ignore Mac fans.
MacDork writes "Well, if default settings in Mac OS X made Lance Ulanoff excited, this is really going to make him do the monkey boy dance... SecurityFocus's Bugtraq mailing list just posted a buffer overflow, in the utility for mounting and probing ISO 9660 file systems. No exploits were mentioned. No word on whether 'Max' alerted Apple or anyone outside of the Bugtraq mailing list though." Also, 'Max' made entirely unfounded, sweeping statements about the general quality of Mac OS X from this one little item, but oh well.
I've seen *tons* of vulnerability releases about companies that contain harsh criticism of their security policies. This is not unusual. At the least, Apple screwed up on an important utility. They can take their lumps, same as everyone else does when they screw up.
When you're on top, you make a tempting target.
Apple isn't "on top" of much of anything that I can think of. Small/midrage servers? That's Linux-dominated. Workstations? That's Windows-dominated. I suppose they have more users than the other BSD variants, for what that's worth.
Frankly, "Max" may be biased. I suspect that he's mostly right -- that the hammered-on and designed-by-folks-with-security-experience BSD code is more reliable than the new stuff Apple churned out. I do know that "MacDork" definitely *is* biased.
I wish editors would reject stories that are just blatently biased, or at least reserve the right to re-summarize story submissions.
Most of the information is more than obvious to anyone interested in running a NOC (incidently, left out of the Slashdot story is that this is a *Security* NOC).
I've seen random Slashdot posts that would be a lot more useful to someone interested in building a NOC than this thing.
That being said, my own two cents:
If you're using SNMP to manage your network, snmpwalk+scripts is good. If you can stomach not using open source software, Intermapper is really nice. Unfortunately, the two big open source competitors don't quite measure up -- Scotty is kind of old and grotty and rather TCL-oriented, and GxSNMP appears to be dead.
Etherape, as suggested in the article, isn't the greatest choice either...IIRC, it doesn't support satellites, which means it needs to be running on the actual network it's monitoring. Not really acceptable for a NOC tool. Etherape is also, in my experience, rather CPU-hungry. There are a lot of commercial traffic flow visualization tools...not sure what's best, as I haven't played with many.
All in all, while the article's worthy of a post in a random discussion, it really isn't worthy of a Slashdot story.
An AC above pointed out that Intel are part of the Trusted Computing group. This all reminds me of Ken Thompsons compiler trojan. (where he hacked a c compiler to add a backdoor whenever it is compiling "login".)
So, what might icc add to the security functions of glibc? to gnupg, sshd, lsh?
You're reaching pretty far with this argument. Intel is a damned large company with a lot of groups working on things and a lot of different opinions and people. They don't have to have a secret, nasty, ulterior motive, even if one group is working on something you don't like.
You want to be paranoid about Intel? Give up -- they control the CPU. They could trojan you much more easily via the proecessor -- no reason to dick around with the compiler.
* ARM is on there. You better avoid any embedded devices. They might be trojaned. Or using any devices in your system (drives, add-in cards) that have ARMs onboard.
* ATI and NVidia are on there. Video cards are clearly out -- there are numerous standards that will let video cards push code to the processor, plus cards tend to have pretty much unstopped access to memory.
* Fujitsu is on there. You want a trojan, a hard disk controller is a damned sweet place to put it.
* Philips is on there. I hope you don't rely on CDs for anything. Who knows what they put in their reference CD drive controller code?
* RSA is in there. A damned large number of companies license their prewritten libraries (and binary copies of the thing, as well). I hope you've never run Netscape Navigator 4.x, because if you did, RSA could be controlling your system, modifying binaries, etc.
* Phoenix is on there. Boy, I hope you don't trust your BIOS for anything. You *are* using LinuxBIOS on a *completely* open-spec'd motherboard, right?
Point is, trying to distrust huge companies because one small component of the company does something you dislike is simply a futile task. Maybe one day you can use all open-source and viewable software, but it isn't going to be in the next decade -- keep in mind all that controller hardware with unbounded privileges to all the goodies on your computer.
Don't get me wrong. I like open source. I write open source. However, being irrationally fanatical about it is both stupid and counterproductive, and doesn't do diddly for the open source movement.
And how many people *use* Amtrak a year, versus how many roads?
Furthermore, even if you had good ratios by those numbers, the problem is that about 10% of the cost will reach about 90% of the people. Beyond that, costs will rise.
Trains may well be cheaper per capita, but you can't argue the case very well based only on the numbers you cited.
Mmmm...pollution happens at power plants, but I'm willing to wager that power plants, which can afford to drop phenomenal fixed costs on cleaners and filters, produce much less pollution per kilowatt-hour than do trains.
I actually read some interesting material about why the US is so poor from a train standpoint.
The inner portions of the US were being settled as trains were being introduced. Settlements sprung up where supplies could be easily moved to -- along rail routes. As a result, most rail in the United States goes right through cities, producing congestion, noise from trains, etc. In England, trains came along well after cities were established, and planning rail growth was actually possible. There are fewer road/rail crossings.
Furthermore, we put a tremendous amount of military, political, and economic pressure to ensure that we have cheap oil. This means cheap (and polluting) car usage. Other countries not only have higher base prices, but tack on tariffs and thus encourage people to use mass transit.
Actually, my understanding was that Iraqi oil was supposed to pay for a significant chunk of all this, but that the industry was pretty wiped out (for the second time) by war, and that it's going to be a couple of years before it can be putting out enough oil to pay for our war costs.
We *do* have a certain responsibility to pay for the reconstruction for Iraq (i.e. it isn't out of the goodness of our heart) given that we were the ones that bombed the shit out of it in the first place.
Have you read these articles? The link you're claiming for reasonable justification for bombing a country, invading it, occupying it at UN censure, jailing its leaders, and taking its oil was the fact that one person had training in the same country that we attacked...how recent was that news again? Gee, it seems we discovered this *after the fact*. The Provisional Authority is tickled pink about this...*after the fact*. They managed to find a tiny shred of legitimacy.
His argument addressed the "vicious leader" aspect many times, with comparisons to China and Afghanistan.
Furthermore, I think it's a pretty tough argument that we invaded because Saddam is a vicious leader. It makes a nice justification, because human issues sell well in the media, but I don't think folks seriously think we invaded because of Saddam's crimes against his people. There are many equally nasty governments around the world.
Given the degree of wild inaccuracy I see in attempts to predict or model how well a product will do in corporate America, I am extremely dubious that our world leaders can, in a highly political climate, make effective estimates about the long-term costs of going to war. Especially since there have been a lot more product launches than wars that the United States has fought.
Re:Let the knee-jerk, left-wing responses begin!
on
Saddam Hussein Arrested
·
· Score: 2, Interesting
Bush tends to be on the conservative side. You don't have to be left-wing -- just centrist -- to criticize him, though I don't think many people actually hate him. He's made a fair number of political mistakes, and doesn't have a reputation for political savvy.
Ashcroft, however, is another story. I don't think *anyone* I know thinks Ashcroft is good news. Ashcroft is a real life incarnation of what Orwell warned us of, and not the kind of person that ever should have reached office.
(I just have to ask...would you rather he still be in power, or in prison?)
It depends. Is the *real* choice that you're giving us the option of invading Iraq against international uproar and throwing him in jail versus having him still in power and us *not* invading Iraq? I'd have prefered to leave well enough alone, actually. We may not have liked Nixon, but neither did we want the Russians to invade, occupy, and toss him in jail, you know?
In any case, Rockstar hasn't comitted any crimes so why is the state threatening them with punishments under the hate crime laws?
It isn't. Some random commissioner (i.e. not important and probably trying to win Haitian votes) "forwarded information on the game to a friend at the Attorney General's office". It's awfully unlikely that the state would go for this case.
IIRC, "inciting to violence" is illegal, which they might try. I'm not really familiar with crimes that fall under it, but I suspect that Rockstar is once again fine. The law is designed for when you have a bunch of people yelling at someone "come on, blow the punk's head off!" -- -- I believe it only applies to speech that would cause immediate violence.
Other than that, I can't imagine what they'd do. They might boycott the game, but they aren't going to be able to smack Rockstar with much of anything.
Rockstar's PR people just decided that the fuss wasn't worth fighting over.
The issue isn't that they're a gang. It's that they're fictional characters in a fictional game where a fictional protagonist is taking fictional action. That should be enough to make the claims of advocating violence against Haitians simply ridiculous. I mean, I should be able to write a book where the main character happens to be a Vichy France collaborator without being attacked for inciting people to violence.
Thre are a lot of other reasons that this should have been thrown out cited here (the character plays both for and against the Haitians, the line never appears in the game, etc, etc, etc). However, the ones I mentioned above should be enough on their own.
Slashdot Mirror
Where do you source your guaranteed bug-free software ?
The whole piece of software isn't bug free. The only thing I'm concerned about is the auth system (generally a relatively small, simple piece of code) being bug free.
It's not an issue if your FTP server has an exploit based on LISTing files if it correctly ignores all input until a valid password is entered, and its handling of that password does not have bugs.
So a firewall is justifiable because knowledgable admins of a managed network "may not have good control over who is connecting to their network", but with novice users sitting directly on the internet at large with no control whatsoever who is connecting to their computers it isn't ?
As I said, these are different types of firewalls -- personal versus traditional.
I'll grant that some sort of system to deal with the fact that some systems ship out-of-box in an awful state would be a good idea. However, all one needs is a piece of software that disables all the extraneous servers running on, say, Windows. Adding a firewall just adds complexity and provides no security benefit above disabling said servers.
Could you back up those claims with facts?
Sure.
First, this is nothing more than an authentication system. It's designed to allow a server to authenticate itself as a trusted source for a domain's email. However, the designers chose to use DNS as a transport mechanism. Not a good idea. DNS is designed to be lightweight and low latency, not to be secure. It's pretty easy to spoof DNS responses. Plus, DNS data tends to get cached. All you need to do is spoof a response, the nameserver's cache is poisoned with false data, and the next N emails (until the cached data expires) are accepted as valid.
Second, this system relies on having everyone implement such functionality. Spammers don't give a damn about return addresses, so they can send email with a from address at any domain. The annoying and ineffective attempts at stopping all open mail relays on the Internet illustrate the failure of this model. A security system that relies on correct implementation over the full Internet to function properly will not work in real life.
Third, this fails to deal with throwaway domains. The authors waffle a bit about them, and finally come out and admit that more mechanisms are required. Dammit, if we had a good PKI trust-ranking system (which is the sort of thing that they are requiring to fix their failings) we wouldn't need this system at *all*, since we could simply sign email and have trust rankings for users.
Enough about the bad design: other reasons I don't like it include:
* The authors have made a decision to make it really annoying to send email from a machine, and have to work with your ISP just to have a mail server. There are plenty of more solid antispam proposed mechanisms that do not place restrictions on who runs what servers (pay-per-email or pay-per-initial-email, PKI systems). This is much more in line with the way the Internet works for most services.
* There is a supposedly trusted authentication system being spread across the entire Internet over an insecure transport protocol.
* DNS caching can make moving an SMTP server or setting up a new one take a significant amount of time.
* IP-based auth isn't a great idea anyway, for a number of reasons. The authors claim that it isn't a huge issue, because IP spoofing is harder (I disagree -- things like Mobile IP have made it harder to *block* IP spoofing).
* Users have no control over what gets blocked. If I *want* to receive email of a particular type, I can't. Two ISPs (sending and receiving) are the ones that determine what mail I can receive). This is perhaps acceptable within a company, but annoying and goes against traditional Internet structure.
* It does nothing to avoid compromised end user machines.
* It does nothing to deal with throwaway accounts.
* It does nothing to deal with misconfigured servers.
No, it's a sign that you are a realist. Whatever patches you download for windows, theres still the RPC ports open, and when know the trouble they've caused recently.
No. Most Microsoft server software is broken WRT to security and should not be used. RPC should not be active.
In addition to this, what if the user opens an attachment that just happens to be a trojan that captures their every key-stroke (including their personal banking passwords and/or credit card no's), connects to the internet and sends this information to the nefarious script kiddie who mailed it out.
Sounds nice, but it's a lost cause. There are zillions of ways to slip past "trojan catchers". One big hole is MSIE -- all you have to do is convince it (in one of many ways) to contact an outside system.
Sorry, but that's absolute bullshit. Operating systems are inherently complex pieces of software that will (despite developers best efforts) contain security vulnerabilities somewhere.
I'm not talking about operating systems (other than the networking stack). I'm talking about remote vulnerabilities. You should not be running flawed servers. The only thing a server should let a remote user do is try to authenticate (and yes, auth code should be well-reviewed code).
If you're an XML nut, you could have XSLT that converts XAML to whatever XML dialect glade uses and just get GTK interfaces directly. :-)
Ocaml has been developed. If you can stand programming in functional languages, you already have a fast language suitable for application programming.
The problem with languages recently is that they aren't driven by CS people, but by businesspeople. Java was not enthusiastically endorsed by language people, but by business technology folks.
The judge didn't say that they were in the right.
He just said that he didn't have enough evidence to issue a preliminary injunction.
The only time these should be issued is if there is immediate, severe, and irrevocable harm being caused by an action, and the judge feels that the harm-causer is unlikely to win their court case.
I'd say this is pretty reasonable. The idea is to keep law from becoming someone's subjective opinion -- the court is where the real arguments will be heard. Preliminary injunctions are emergency actions, not to be taken in every case.
Since not having a firewall opens you to many other abuses than just Messenger popups, better advice to affected users might be to get the free Kerio Personal Firewall, or another firewall product.
Getting a firewall and not disabling the Messenger Service also allows the several other Windows services that use Messenger for reporting to the end-user to continue to make those reports.
I can't agree.
I've found the "personal firewall" to be one of the biggest disasters in recent memory. It has essentially no utility to almost any users.
It tends to get users worried about attacks that they could otherwise just ignore.
They may have bugs themselves or impact performance.
They cost money.
Requiring a firewall is *always* a sign that you are either using broken software or you have misconfigured your software. Messenger is decidedly broken. It has a completely broken authentication model.
In a normal system, any servers you have running should (a) support authentication and (b) not allow remote attacks inward. I never use firewalls for my small networks, because it's entirely unnecessary. If I manage to mask a security problem by slapping up a firewall, all that means is that I now have a security vulnerability that can be exploited if someone manages to get inside my network. I should secure my systems properly.
(Note that non-personal firewalls *do* have a legitimate use -- IT may not have good control over who is connecting what to their network, and furthermore, the additional time that a network-wide firewall may give when a worm outbreak comes along may be enough time to finish testing and deploying a patch).
I do not use firewalls on any of the systems I run. There is no reason to do so if the system is properly configured.
There are a couple of reasons:
* Familiarity. Just as most people aren't willing to learn a new (possibly significantly superior) control interface to their car, most people don't want to relearn an interface to their computer.
* Software availability. Lots of custom and vertical-market software and games are only available for Windows.
* Lock-in. Microsoft is actively making it unpleasant to switch from their software.
From a security standpoint, this is a dumb idea. Really dumb. It's stupid, open to a ton of attacks, and does diddly about spam. However, it's probably going to get some popularity for the following reasons:
* Folks hate spam, and will glom onto anything that claims to reduce it with the gullibility of a cancer victim being scammed by a faith healer.
* It's easy for IT folks to implement. The CIO can say that he "implemented an initiative to reduce the most frequent user complaint, saving the company N dollars". He doesn't give a damn about whether he actually *accomplishes* anything, just whether it looks good.
* SPF is a pet project of someone. Obviously not someone who's a security person, but someone.
* There's money in it for consultants. The firewall craze made many many people very much money. The promise of a *new* even less useful system that can be used to pry money from companies is quite appealing.
Things that *could* reasonably be done to combat spam:
* Limit email amplification.
* Require one of a number of pay or auth systems for email.
* Whitelisting
* Allowing clients to publish rules to mail servers (so that a client whitelist, for instance, would allow a server to avoid soaking up any bandwidth at all...this would be a useful set of IMAP extensions).
Frankly, unless a bunch of engineers get together and put out a *useful* RFC (i.e. not this crap) a la PNG, there's probably going to be an industry consortium that decides what to do. And standards committes have an awfully low rate of getting-it-right.
Blind, stupid fanaticism doesn't do anything to help Apple -- it just means that people ignore Mac fans.
MacDork writes "Well, if default settings in Mac OS X made Lance Ulanoff excited, this is really going to make him do the monkey boy dance... SecurityFocus's Bugtraq mailing list just posted a buffer overflow, in the utility for mounting and probing ISO 9660 file systems. No exploits were mentioned. No word on whether 'Max' alerted Apple or anyone outside of the Bugtraq mailing list though." Also, 'Max' made entirely unfounded, sweeping statements about the general quality of Mac OS X from this one little item, but oh well.
I've seen *tons* of vulnerability releases about companies that contain harsh criticism of their security policies. This is not unusual. At the least, Apple screwed up on an important utility. They can take their lumps, same as everyone else does when they screw up.
When you're on top, you make a tempting target.
Apple isn't "on top" of much of anything that I can think of. Small/midrage servers? That's Linux-dominated. Workstations? That's Windows-dominated. I suppose they have more users than the other BSD variants, for what that's worth.
Frankly, "Max" may be biased. I suspect that he's mostly right -- that the hammered-on and designed-by-folks-with-security-experience BSD code is more reliable than the new stuff Apple churned out. I do know that "MacDork" definitely *is* biased.
I wish editors would reject stories that are just blatently biased, or at least reserve the right to re-summarize story submissions.
I'm not sure what body of water you're thinking of, but I'm pretty sure it's not the Bering Strait. The Bering Strait separates Alaska and Russia.
There is *not* a heck of a lot of content here.
Most of the information is more than obvious to anyone interested in running a NOC (incidently, left out of the Slashdot story is that this is a *Security* NOC).
I've seen random Slashdot posts that would be a lot more useful to someone interested in building a NOC than this thing.
That being said, my own two cents:
If you're using SNMP to manage your network, snmpwalk+scripts is good. If you can stomach not using open source software, Intermapper is really nice. Unfortunately, the two big open source competitors don't quite measure up -- Scotty is kind of old and grotty and rather TCL-oriented, and GxSNMP appears to be dead.
Etherape, as suggested in the article, isn't the greatest choice either...IIRC, it doesn't support satellites, which means it needs to be running on the actual network it's monitoring. Not really acceptable for a NOC tool. Etherape is also, in my experience, rather CPU-hungry. There are a lot of commercial traffic flow visualization tools...not sure what's best, as I haven't played with many.
All in all, while the article's worthy of a post in a random discussion, it really isn't worthy of a Slashdot story.
An AC above pointed out that Intel are part of the Trusted Computing group. This all reminds me of Ken Thompsons compiler trojan. (where he hacked a c compiler to add a backdoor whenever it is compiling "login".)
So, what might icc add to the security functions of glibc? to gnupg, sshd, lsh?
You're reaching pretty far with this argument. Intel is a damned large company with a lot of groups working on things and a lot of different opinions and people. They don't have to have a secret, nasty, ulterior motive, even if one group is working on something you don't like.
You want to be paranoid about Intel? Give up -- they control the CPU. They could trojan you much more easily via the proecessor -- no reason to dick around with the compiler.
Plus, look at the Trusted Computing Group membership list. Do you distrust all products from all of these companies?
Let's see:
* ARM is on there. You better avoid any embedded devices. They might be trojaned. Or using any devices in your system (drives, add-in cards) that have ARMs onboard.
* ATI and NVidia are on there. Video cards are clearly out -- there are numerous standards that will let video cards push code to the processor, plus cards tend to have pretty much unstopped access to memory.
* Fujitsu is on there. You want a trojan, a hard disk controller is a damned sweet place to put it.
* Philips is on there. I hope you don't rely on CDs for anything. Who knows what they put in their reference CD drive controller code?
* RSA is in there. A damned large number of companies license their prewritten libraries (and binary copies of the thing, as well). I hope you've never run Netscape Navigator 4.x, because if you did, RSA could be controlling your system, modifying binaries, etc.
* Phoenix is on there. Boy, I hope you don't trust your BIOS for anything. You *are* using LinuxBIOS on a *completely* open-spec'd motherboard, right?
Point is, trying to distrust huge companies because one small component of the company does something you dislike is simply a futile task. Maybe one day you can use all open-source and viewable software, but it isn't going to be in the next decade -- keep in mind all that controller hardware with unbounded privileges to all the goodies on your computer.
Don't get me wrong. I like open source. I write open source. However, being irrationally fanatical about it is both stupid and counterproductive, and doesn't do diddly for the open source movement.
It'd be awfully nice to have version numbers on this thing.
And how many people *use* Amtrak a year, versus how many roads?
Furthermore, even if you had good ratios by those numbers, the problem is that about 10% of the cost will reach about 90% of the people. Beyond that, costs will rise.
Trains may well be cheaper per capita, but you can't argue the case very well based only on the numbers you cited.
Mmmm...pollution happens at power plants, but I'm willing to wager that power plants, which can afford to drop phenomenal fixed costs on cleaners and filters, produce much less pollution per kilowatt-hour than do trains.
I actually read some interesting material about why the US is so poor from a train standpoint.
The inner portions of the US were being settled as trains were being introduced. Settlements sprung up where supplies could be easily moved to -- along rail routes. As a result, most rail in the United States goes right through cities, producing congestion, noise from trains, etc. In England, trains came along well after cities were established, and planning rail growth was actually possible. There are fewer road/rail crossings.
Furthermore, we put a tremendous amount of military, political, and economic pressure to ensure that we have cheap oil. This means cheap (and polluting) car usage. Other countries not only have higher base prices, but tack on tariffs and thus encourage people to use mass transit.
We don't even have enough users to keep our regular rail lines going without massive government bailouts.
Actually, my understanding was that Iraqi oil was supposed to pay for a significant chunk of all this, but that the industry was pretty wiped out (for the second time) by war, and that it's going to be a couple of years before it can be putting out enough oil to pay for our war costs.
We *do* have a certain responsibility to pay for the reconstruction for Iraq (i.e. it isn't out of the goodness of our heart) given that we were the ones that bombed the shit out of it in the first place.
Have you read these articles? The link you're claiming for reasonable justification for bombing a country, invading it, occupying it at UN censure, jailing its leaders, and taking its oil was the fact that one person had training in the same country that we attacked...how recent was that news again? Gee, it seems we discovered this *after the fact*. The Provisional Authority is tickled pink about this...*after the fact*. They managed to find a tiny shred of legitimacy.
His argument addressed the "vicious leader" aspect many times, with comparisons to China and Afghanistan.
Furthermore, I think it's a pretty tough argument that we invaded because Saddam is a vicious leader. It makes a nice justification, because human issues sell well in the media, but I don't think folks seriously think we invaded because of Saddam's crimes against his people. There are many equally nasty governments around the world.
Given the degree of wild inaccuracy I see in attempts to predict or model how well a product will do in corporate America, I am extremely dubious that our world leaders can, in a highly political climate, make effective estimates about the long-term costs of going to war. Especially since there have been a lot more product launches than wars that the United States has fought.
Bush tends to be on the conservative side. You don't have to be left-wing -- just centrist -- to criticize him, though I don't think many people actually hate him. He's made a fair number of political mistakes, and doesn't have a reputation for political savvy.
Ashcroft, however, is another story. I don't think *anyone* I know thinks Ashcroft is good news. Ashcroft is a real life incarnation of what Orwell warned us of, and not the kind of person that ever should have reached office.
(I just have to ask...would you rather he still be in power, or in prison?)
It depends. Is the *real* choice that you're giving us the option of invading Iraq against international uproar and throwing him in jail versus having him still in power and us *not* invading Iraq? I'd have prefered to leave well enough alone, actually. We may not have liked Nixon, but neither did we want the Russians to invade, occupy, and toss him in jail, you know?
In any case, Rockstar hasn't comitted any crimes so why is the state threatening them with punishments under the hate crime laws?
It isn't. Some random commissioner (i.e. not important and probably trying to win Haitian votes) "forwarded information on the game to a friend at the Attorney General's office". It's awfully unlikely that the state would go for this case.
IIRC, "inciting to violence" is illegal, which they might try. I'm not really familiar with crimes that fall under it, but I suspect that Rockstar is once again fine. The law is designed for when you have a bunch of people yelling at someone "come on, blow the punk's head off!" -- -- I believe it only applies to speech that would cause immediate violence.
Other than that, I can't imagine what they'd do. They might boycott the game, but they aren't going to be able to smack Rockstar with much of anything.
Rockstar's PR people just decided that the fuss wasn't worth fighting over.
The issue isn't that they're a gang. It's that they're fictional characters in a fictional game where a fictional protagonist is taking fictional action. That should be enough to make the claims of advocating violence against Haitians simply ridiculous. I mean, I should be able to write a book where the main character happens to be a Vichy France collaborator without being attacked for inciting people to violence.
Thre are a lot of other reasons that this should have been thrown out cited here (the character plays both for and against the Haitians, the line never appears in the game, etc, etc, etc). However, the ones I mentioned above should be enough on their own.
I wish more people just watched their Kindergarten teacher tell them that 'shutted' is not a word.
Really? My beef is people that ignored their teacher telling them not to randomly capitalize words and to use double quotes around quoted text.