... of SCO products to look for inclusion of GPL code? There has been some evidence that such inclusions or copying has occurred.
Could you please be specific about that evidence?
There has been some speculation and guesswork that SCO copied linux code for their linux kernel personality module. But so far, as nearly as I can tell, it's all just suspicion.
So, if there really is evidence, please reply with a link or some other solid reference.
If not, and this is mere suspicion, please see if as an unsubstantiated claim (you know, sorta like what SCO's been doing all along)
At the risk of/. blaspheme (trying to understand SCO's arguement rather than immediately discounting it)....
I don't get it. How can the GPL be unconstitutional ?
The basic arguement seem to be that the constitution states the purpose of copyright is the "promote progress of science..." AND the supreme court recently wrote "motive of profit is the engine that ensures progress of science".
There's certainly no disputing that the constitution really does have that, and that the court really did write such an opinon recently.
They claim the GPL is designed to destroy the profit motive. Suspecd disbelief for a moment and ignore the scant profit Redhat made a couple times.
So, if you put these three things together, you get:
They want to distract the press by publishing this letter.
Indeed. That's why it was published on Dec 4th... one day before Dec 5th when the judge has scheduled oral arguements the 3 motions to compel discovery (2 by IBM against SCO and 1 by SCO against IBM).
I'm not going to make predictions about what the judge will say or do tommorrow... but I will predict that this diversionary tactic doesn't prevent coverage of whatever the judge says.
Apparntly I can buy some herbs that'll add 3 inches length to my penis, and easily eliminate all my bad debt, and get any medication I want at a deep discount without a prescription, and get all the pay-for-view cable channels without paying, and lose weight without diet or excersize, and make thousands of dollars every week without doing any real work, and simply order a diploma for any degree I want, and get my share of millions of dollars left in an abandoned Nigerian bank account, and get a great deal on magician show supplies!
I believe there were a number of products for windows 3.1 which added long filename support, using a variety of different techniques.... but all of them ultimately leaving the original 8.3's in place, thus establishing a dual name space as described in the patent.
What would be really nice (hint, hint, anyone from Mandrake reading this) would be for the unused portion of the key to also be usable as a "normal" USB key to transport data around between machines (running that other, monopoly-based OS)
Saddly, FAT16 is the standard format for USB keys, with the slow cluster chain following rather than fast inode structure, and without unix semantics like permissions, device files, hard links, and so on.
Maybe they'd allocate a big file and mount it with a loopback device? Or maybe they'll use on of the other mechanisms to make up for FAT filesystem limitations? Or maybe they'll just require the key to have an EXT2 or other "linux native" filesystem? But that would make the key unusable for the thing that makes those little keys so compelling... moving data around.
It's be pretty sad to have to carry 2 USB keys around, one for moving data between systems and a second one for MandrakeMove (or other distros that follow in their footsteps).
This is slashdot, you know... What business does anyone have actually following links? Next thing you know, someone like you might actually read the linked text/article. How insightful would that be?
The existance of "best practice" guidelines does not presuppose that everyone will follow them.
If you read the parent post, you will see that "muffen (321442)" suggested that
"this guy should have told Microsoft first, waited, if they don't respond within 48 hours, report it."
Now, to specificly respond to the four questions in your post:
Did you tell eveyone in China that they were to play by your rules, that is, "best practices?"
No, I did not instruct anyone to do anything. I simply stated that 1 week is considered a "best practice", rather than 48 hours.
You used the words "your rules", implying that I made up the 1 week and 1 month times. In fact, 1 week is the suggested time in the BugTraq FAQ. I believe 1 month has been mentioned in a draft RFC regarding these matters, though allowing the vendor extensions in good faith (but not excessive stalling) is certainly a good idea.
You obviously missed the parent post, which I quoted for you, so you would know that the topic of conversation was wether 48 hours or 1 week would be an appropriate time to wait for a response from Microsoft. You somehow mistook discussion of what "should" be done, and what is considered "best practice" with a commanding directive.
What did you use for the "or else" clause?
Then, you launch into enforcement, when in fact nobody (at least in this thread) has directed anybody to do anything.... only discussed what "should" have been done.
Why do you think a US corporation has any control over this?
This is a question best answered with another question. What misled you to believe discussion of "best practices" that "should" be followed was somehow a directive, commanding anyone to follow the suggestion?
How would you even begin to implement such a control, and why do you think that would work against China?
Perhaps such control is impossible. Even a law forbidding such untimely disclosures could not stuff the genie back in the bottle.
But even in the absence of law or other formal rules, social pressure is a strong motivating force. Simply having published and widely agreed upon rules of conduct ("best practices") has been a step forward. Unlike this incident, most "security researchers" publish their findings, at least partially, for a few moments of fame. Companies who sell security product or services want positive attention. Many of the security vulunerability disclosures in the last year have included a timeline of disclosure, to illustrate that the disclosure followed established best practices.
.
So, please, if you can, try to separate in your mind the importance of having well established guidelines for disclosure, and the issue of what will motivate individuals and organizations to follow them. I have commented only on the former. Encouragement and enforcement are a separate matter.
A sensible protocol to follow while reporting a security vulnerability is as follows:
Contact the product's vendor or maintainer and give them a one week period to respond. If they don't respond post to the list.
If you do hear from the vendor give them what you consider appropriate time to fix the vulnerability. This will depend on the vulnerability and the product. It's up to you to make and estimate. If they don't respond in time post to the list.
If they contact you asking for more time consider extending the deadline in good faith. If they continually fail to meet the deadline post to the list.
While this text says "appropriate time to fix the vulnerability", I've seen the 1 month estimate thrown around many times. I did not make it up either, but it's not as trivial to find as the 1 week guideline. It is true that some types of bugs should be fixed (and tested) more rapidly while others may take longer, so perhaps this bugtraq guideline is best. But "right now or else" and "within hours" are certainly unreasonable.
Witness the recent openssh bug, which was fixed within a day (possibly several hours). Then, only a day or two later, yet another patch was issued because another instance of essentially the same problem was discovered in the course of testing the first fix. At least it didn't break anything... but there have been plenty of examples of quickly-released patches that did break something because there was not enough time for testing. My point is that is it IS reasonable for the fix to take a bit of time, in the interest of getting it done correctly and testing it well, especially if the bug isn't currently being exploited and exploits aren't immenent because of public disclosure.
Re:Immediate full disclosure is best security prac
on
New IE Holes Discovered
·
· Score: 2, Interesting
Prove it. Anything that can be found by a white/gray hat can be found or was already found by a black hat.
Undoubtedly, you would look upon the history of the last few years, where virtually all attacks (manual and automated in virus/worm code) have exploited known bugs for which patches had been available for weeks or months, and say "that's not PROOF".
And in a mathematical sense, that would indeed not be "proof".
The best anyone can offer you is a "preponderance of the evidence", which might even be "beyond a reasonable doubt" that virtually all sucessful attacks have exploited known vulnerabilities for which the vendor had already created and published a patch.
If you can accept this rather obvious observation, and you can believe that the trend will continue, then it is a very small logical step to conclude that it is overwhelmingly in everyone's best interest for vendors to have a reasonable opportunity to create and publish patches before details of new vulnerabilities are publically announced.
But there is no proof, only a well established trend. So you, supposedly a system administrator, would rather see immediate public disclosure. I'm sure that will appeal to your emotional well being... not being kept in the dark. It will also mean, that as a system administrator, you will need to make temporary workarounds (which often times means shutting off the affected service), while you then wait, with a greatly increased probability of attack attempts. But it will appeal to you emotionally, making you feel better that the vendor got their "feet held to the fire". That ought to make up for the extra time you'll spend implementing the workaround and interfacing with all your users and managers and explaining to them why a service they depend upon (and consider your job to keep operational) is not available temporarily.
There are, of course, some times when you have to use IE (like Windows Update...
In the last several years of using Redhat, and slackware before that, and macintosh OS 6/7 before that, and the apple ][ before that..... I have never, not even once, had to use IE for anything (like Windows Update).
this guy should have told Microsoft first, waited, if they don't respond within 48 hours, report it.
I believe the current "best practice" is to wait at least 1 week for the vendor to initially respond... and to give them at least 1 month to create a patch if they (privately) acknowledge the problem.
But giving them ZERO hours is about as bad as it gets.
Most spam that ends up in U.S. mailboxes comes from overseas
But it is send on behalf of companies within the US, selling products targeted at the US market, to US citizens. Make any of these illegal and vigorously enforced, and most of the current spam will stop.
Make it so addresses can not be spoofed, email headers can't be forged and [snip, IP number authentication]. I think if you fixed this, then a lot of the spam would just go away.
The unfortunate obstacle to implementing this is that a good portion of all legitimate email transmitted today is misconfigured, and effective "forges" its sender address. Examples include people who send "from their work address" using their home computer and ISP (no VPN connection to the corporate email server). Likewise for sending as if from yahoo or hotmail, using your ISP rather than having to use the web interface. Sales people and other road warriors often depend on being able to transmit email from within a hotel room or off-site location, using whatever mailserver they can find. "Vanity domain names" are also a big issue, since nearly all of these are hosted by an ISP who simply forwards received messages, and transmitted messages are effectively "forged". There are also a large number of organizations that simply haven't configured outgoing mail properly, sometimes at the server, and more problematically on hundreds or thousands of client machines which all send through some mail server, effectively "forging" their outbound mail.
SPF is the leading effort right now to add simple, IP-number based sender domain name authentication to existing email. (the others were RMX and DMP). SPF allows many different ways (called "mechanisms" in the spec) to check if the transmitting IP number is authorized to send for that domain name. You can read all about it at the SPF site by following that link.
But despite SPF's simplict and backwards compatibility (and the very similar RMX and DMP proposals), there has been massive objection to it. For a truely sad tale of these objections, search for the draft proposals of RMX and scroll to the section near the end about the objections raised. For anyone who believes some technical improvements to adding authentication to SMTP, or replacing SMTP, is a viable solution to stopping spam... reading about the objections in the RMX draft should be a sobering wake-up call and put the enormous inertia of SMTP's forgability into perspective.
SpamAssassin's Bayesian filter doesn't become enabled until it's auto-learned from at least 200 spam and non-spam (or "ham") messages.
Since he didn't discuss his methodology, and admitted not feeding the same stream of messages into all 5 filters, and we know he didn't do much investigage (likely because he's a gui-only guy), it seems pretty likely he ran it on incoming messages for a day, or perhaps only several hours... not long enough for the Bayesian filter to activate.
In mid-September, a
rumor
was reported that Ford was "considering" a switch for servers. Somehow that turned into a rumor of a massive desktop migration.
A few weeks later, Ford
announced they were NOT going to switch desktops to linux
(google cache, original article off-line now). Ford specifically mentioned just signing a 3 year contract with Microsoft. Perhaps the rumor was used as legerage to get a better deal from MS, or perhaps it was just the case of wishful thinking and sloppy reporting.
Here's slashdot's coverage with more links. Notice the update, posted several hours later (probably long after most slashdot readers had long since stopped seeing it)... with the link to a newsforge story, aptly titled
Ford move to Linux not true (yet). It was all a rumor that got blown out of proportion.
they don't send commands to eachother, but the master constrains the clocking on the bus and the slave is, well, slaved to the clocking the master negotiates.
This is simply incorrect.
The host (your PC) queries both drives using the device identify command, and receives a 512 byte clock of information about each device (if each is present).
While it is true that the 2 devices do not send commands to each other, during startup diagnostics, they do communicate with each other on the "PDIAG" line. The google search you gave returns many datasheets that refer to this "IDE handshake" during startup diagnostics, and also have "clocking" somewhere else in the document.
The truth is that the host (PC) controls the clocking for each device. The master device does not control what clock the host chooses for the slave device.
That is why you must have a master even if there is no slave.
There is no such requirement, other than old bioses which do not properly check for a slave device is the master is not present. Virtually all modern bioses check for a slave-only configuration. Also, most modern operating systems will autodetect the hardware, regardless of the bios detection.
The question is, will anyone remember SCO in 5 years
This is a question best answered with another question...
Does anyone remember Della Croce, who falsely registered the trademark "linux" and attempted to extort licensing fees from the various companies who were selling cdroms (back then, many people purchased cdrom rather than downloaded ISOs).
At the time, it seems to drag on forever. Ultimately, the patent and trademark office assigned ownership of the registered "linux" trademark to Linus Torvalds.
In 6-7 years from now (based on the assumption SCO will lose or implode in 2004 or 2005), SCO will probably be a long distant memory, and the result will be absolutely no doubt about the validity of the GPL and openness which allows infrigements to be seen... just as today there is absolutely no doubt about the trademark, all thanks to the unscrupulous efforts (now mostly forgotten) Della Croce.
Quoting, so in case you don't want to follow that link and leave the comfort of slashdot:
Keep a low profile and do not divulge details on Linux deployments.
Until a judgment in a case would unequivocally warrant it, Linux users should not pay SCO the license fees it has asked for to settle its allegations of infringement of intellectual property rights.
Do not permit SCO to audit your premises without legal authorization.
Admittedly, Garner does recommend delaying new high-performance deployments for a few months to see what happens with SCO.
Linux can survive the current dispute, but only on its own merits
Or perhaps you want to know what IDC really thinks rather than just a survey result. Well, quoting once more (though you could easily follow the link to see this same text):
"The Unix market continues to struggle with competitive pressures from both Windows and Linux operating environments. While the decline in 2002 was less severe than the decline we saw in 2001, Unix vendors are faced with challenging market conditions," said Al Gillen, research director for the System Software service at IDC. "Looking ahead, we don't see a significant recovery for the Unix operating environments market during our forecast period."
Notice that this was written only last month. Apparantly they don't think SCO's going to have much impact.
Saddly, there any many other IDC documents where you have to pay to even find out their opinion... the abstracts are so generic you don't even get a hint until you pay. But I suppose that's how the stay in business.
The SPAM wars will be fought and won with innovative technology
Really? Filters perhaps, but certainly not anything fundamental at the protocol level.
The simplest and most backwards compatible approaches under consideration are IP-number-based sender authentication. These don't require any significant changes to SMTP/ESMTP, and they can be adopted gradually and interoperate with systems not yet deploying them. SPF is probably one most likely to be adopted. The basic idea is to provide a mechanism for a receipient to check if the IP number of the transmitting SMTP server is one of the IP numbers authorized to transmit messages for that domain (existing MX records only tell you the IP number which is to receiving incoming messages).
But there has been considerable resistance to even these relatively simple, very compatible, easily implemented ideas.
The ugly truth is that LOTS of legitimate email takes advantage of SMTP's complete lack of sender authentication. Adding even very simple and relatively weak sender authentication is going to create a LOT of pain for everyone with improperly configured outgoing mail, and for message forwarding.
The USA. Well, maybe not exactly 95%, but certainly the vast majority is sent by people in the USA, plugging "products" targeted at US citizens. Spamhaus is currently not responding, otherwise I'd provide a link to the page with their research about the big spammers. They're almost all in the USA.
The fact that messages originate from open relays in Asia does not change the fact that the people responsible for sending those messages are in the US.
What is to stop spammers... from using this Do-not-spam list as a database
Enforcement of the law. If the law isn't enforced, it won't discourage any of them. But if it is (and we can only hope), and some spammers get a criminal conviction with jail time, it will likely cause other spammers to stop, or move overseas.
We can only hope a number of prosecuters out there have been refraining because there weren't any specific laws and the prospects for putting spammers behind bars were slim. If that changes, we can optimistically hope a number of attorney generals in various states (cough, Florida, cough) will "make an example" out of their state's notorious spammers... and of course make a big public scene about what heros they are for it.
Nice of you to appologize for Redhat. They certainly need some appologists. But I have some problems accepting some of these things....
1) He said it's complementary for the duration of your RHN contract and there is a discount available for after that.
No. He said "For those in this position, entitlements to both Red Hat Enterprise Linux ES and WS will be made available for the remainder of the subscriptions". But he did not say you'd get a complementary copy of Enterprise. He did specifically say "discounts are available for Red Hat Enterprise Linux to any RHN customer".
So, if you pay a fee (admittedly discounted) for Enterprise, you can continue using your existing RHN entitlements (which you've already fully paid). If Redhat really is offering current, fully-paid RHN customers a complementary copy of any version of the Redhat Enterprise Linux, please point out where they specifically make such an offer. If you do, I will admit that you were correct and I was mistake. But after re-reading his answers again, and also checking the email I received (I paid for RHN), I have seen no such offer.
He also said Fedora will have a similar up2date utility. But the subject of Fedora's continuance of updates for 2-3 months after subsequent releases was of course not mentioned.
2) Umm, ok, who cares if they don't have a product for small business.
Small businesses probably care. You know, the ones who have found RH9 a good product and until recently believe they could depend on Redhat to continue it.
5) They're still in business, aren't they? The couldn't have made any really big mistakes then.
It is arrogant to refuse to admit ever having made any mistakes. It is foolish to believe they've never made any unwise decisions.
In the dot-com days, sortly after their very successful IPO, Redhat went on a spending spree and purchased several small companies. Not long thereafter, they basically discontinued those products and laid off the employees. One example as HKS, makers of CCVS (credit card verification system), which was open-source. Thanks to Redhat, CCVS no longer exists, and there isn't really an open-source credit card processing software package anymore.
.
But more than any one specific point, Matthew's answers were evasive. He dodged the certral point of most of the questions.
I wasn't very impressed. Maybe I'm just bitter about having to migrate from RH9 to "something else"... which will probably be Debian rather than Fedora (due to Fedora's very short maintainance schedule).
Here's roughly how I read his answers:
1) Your fully paid RHN subscriptions for RH9 will be worthless. You can't have a refund, but you can pay even more for a (discounted but not complementary) upgrade to the enterprise version, to keep using your already-paid RHN entitlements. And yes, we can almost admit the SSL problem that broke RHN was our fault, but rather than appologizing, it was actually due to our excellent security policy.
2) No actual recommendation for small business. Dodge the question by babbling about what a small business is, and something about "Differentiated services skills" during the transition from proprietary to open source deployment. Yeah, sure Roblimo, that's not PR speak! I've got a nice bridge for sale too. Wanna meet in Brooklin to see it?
3) Slashdot readers should be content with Fedora, but everyone who works for a living should pay for various versions of Redhat Enterprise Linux. Non-technical home users should use Microsoft.
4) Redhat decided only to focus on enterprise. Hint that WS is meant to be a client, but ultimately dodge question about advantage of offering "full package" including both desktop and client.
5) Redhat has never made a mistake, even in the dot-com days.
6) Promise to stay with GPL and collaborate with open source community.
7) Hardware support won't come until a large user base demands it. Fedora is supposed to build that user base. Dodge the question about discontinuance of RH9 affecting growth of hardware demand.
8) Shrink wrapped product didn't make enough money and couldn't grow (but no admission it was unprofitable, despite the well-known fact that Redhat was always in the red all those years).
9) Matt user linux and gnome at home.
10) Call us regarding your educational discount... because we won't say anything specific in public.
Slashdot Mirror
Could you please be specific about that evidence?
There has been some speculation and guesswork that SCO copied linux code for their linux kernel personality module. But so far, as nearly as I can tell, it's all just suspicion.
So, if there really is evidence, please reply with a link or some other solid reference.
If not, and this is mere suspicion, please see if as an unsubstantiated claim (you know, sorta like what SCO's been doing all along)
I actually found this to be one of the best summaries so far.
I don't get it. How can the GPL be unconstitutional ?
The basic arguement seem to be that the constitution states the purpose of copyright is the "promote progress of science..." AND the supreme court recently wrote "motive of profit is the engine that ensures progress of science".
There's certainly no disputing that the constitution really does have that, and that the court really did write such an opinon recently.
They claim the GPL is designed to destroy the profit motive. Suspecd disbelief for a moment and ignore the scant profit Redhat made a couple times.
So, if you put these three things together, you get:
I personally suspect there are a dozen reasons why this argument is bad. But that is, as nearly as I can tell from the letter, the basic arguement.
Indeed. That's why it was published on Dec 4th... one day before Dec 5th when the judge has scheduled oral arguements the 3 motions to compel discovery (2 by IBM against SCO and 1 by SCO against IBM).
I'm not going to make predictions about what the judge will say or do tommorrow... but I will predict that this diversionary tactic doesn't prevent coverage of whatever the judge says.
Apparntly I can buy some herbs that'll add 3 inches length to my penis, and easily eliminate all my bad debt, and get any medication I want at a deep discount without a prescription, and get all the pay-for-view cable channels without paying, and lose weight without diet or excersize, and make thousands of dollars every week without doing any real work, and simply order a diploma for any degree I want, and get my share of millions of dollars left in an abandoned Nigerian bank account, and get a great deal on magician show supplies!
Were any of those early enough to be prior art?
I wonder how this supposedly applies ($0.25 each) to blank flash cards, which have neither any filenames nor an operating system on them!
Saddly, FAT16 is the standard format for USB keys, with the slow cluster chain following rather than fast inode structure, and without unix semantics like permissions, device files, hard links, and so on.
Maybe they'd allocate a big file and mount it with a loopback device? Or maybe they'll use on of the other mechanisms to make up for FAT filesystem limitations? Or maybe they'll just require the key to have an EXT2 or other "linux native" filesystem? But that would make the key unusable for the thing that makes those little keys so compelling... moving data around.
It's be pretty sad to have to carry 2 USB keys around, one for moving data between systems and a second one for MandrakeMove (or other distros that follow in their footsteps).
My god man, what were you thinking ?!?!
This is slashdot, you know... What business does anyone have actually following links? Next thing you know, someone like you might actually read the linked text/article. How insightful would that be?
Saddly, we are talking about far more than Microsoft here.
This disclosure does more than hurt Microsoft's already-tarnished reputation. It increases the risk to millions of ordinary people and organizations.
if this is giving microsoft a hard time, then more of it is needed.
I too feel no sympathy for Microsoft. But risking millions of ordinary people as Collateral Damage is far beyond what we need more of.
If you read the parent post, you will see that "muffen (321442)" suggested that "this guy should have told Microsoft first, waited, if they don't respond within 48 hours, report it."
Now, to specificly respond to the four questions in your post:
Did you tell eveyone in China that they were to play by your rules, that is, "best practices?"
No, I did not instruct anyone to do anything. I simply stated that 1 week is considered a "best practice", rather than 48 hours.
You used the words "your rules", implying that I made up the 1 week and 1 month times. In fact, 1 week is the suggested time in the BugTraq FAQ. I believe 1 month has been mentioned in a draft RFC regarding these matters, though allowing the vendor extensions in good faith (but not excessive stalling) is certainly a good idea.
You obviously missed the parent post, which I quoted for you, so you would know that the topic of conversation was wether 48 hours or 1 week would be an appropriate time to wait for a response from Microsoft. You somehow mistook discussion of what "should" be done, and what is considered "best practice" with a commanding directive.
What did you use for the "or else" clause?
Then, you launch into enforcement, when in fact nobody (at least in this thread) has directed anybody to do anything.... only discussed what "should" have been done.
Why do you think a US corporation has any control over this?
This is a question best answered with another question. What misled you to believe discussion of "best practices" that "should" be followed was somehow a directive, commanding anyone to follow the suggestion?
How would you even begin to implement such a control, and why do you think that would work against China?
Perhaps such control is impossible. Even a law forbidding such untimely disclosures could not stuff the genie back in the bottle.
But even in the absence of law or other formal rules, social pressure is a strong motivating force. Simply having published and widely agreed upon rules of conduct ("best practices") has been a step forward. Unlike this incident, most "security researchers" publish their findings, at least partially, for a few moments of fame. Companies who sell security product or services want positive attention. Many of the security vulunerability disclosures in the last year have included a timeline of disclosure, to illustrate that the disclosure followed established best practices.
.
So, please, if you can, try to separate in your mind the importance of having well established guidelines for disclosure, and the issue of what will motivate individuals and organizations to follow them. I have commented only on the former. Encouragement and enforcement are a separate matter.
BugTraq FAQ, 0.1.8 What is the proper protocol to report a security vulnerability?
Quoting:
While this text says "appropriate time to fix the vulnerability", I've seen the 1 month estimate thrown around many times. I did not make it up either, but it's not as trivial to find as the 1 week guideline. It is true that some types of bugs should be fixed (and tested) more rapidly while others may take longer, so perhaps this bugtraq guideline is best. But "right now or else" and "within hours" are certainly unreasonable.
Witness the recent openssh bug, which was fixed within a day (possibly several hours). Then, only a day or two later, yet another patch was issued because another instance of essentially the same problem was discovered in the course of testing the first fix. At least it didn't break anything... but there have been plenty of examples of quickly-released patches that did break something because there was not enough time for testing. My point is that is it IS reasonable for the fix to take a bit of time, in the interest of getting it done correctly and testing it well, especially if the bug isn't currently being exploited and exploits aren't immenent because of public disclosure.
Undoubtedly, you would look upon the history of the last few years, where virtually all attacks (manual and automated in virus/worm code) have exploited known bugs for which patches had been available for weeks or months, and say "that's not PROOF".
And in a mathematical sense, that would indeed not be "proof".
The best anyone can offer you is a "preponderance of the evidence", which might even be "beyond a reasonable doubt" that virtually all sucessful attacks have exploited known vulnerabilities for which the vendor had already created and published a patch.
If you can accept this rather obvious observation, and you can believe that the trend will continue, then it is a very small logical step to conclude that it is overwhelmingly in everyone's best interest for vendors to have a reasonable opportunity to create and publish patches before details of new vulnerabilities are publically announced.
But there is no proof, only a well established trend. So you, supposedly a system administrator, would rather see immediate public disclosure. I'm sure that will appeal to your emotional well being... not being kept in the dark. It will also mean, that as a system administrator, you will need to make temporary workarounds (which often times means shutting off the affected service), while you then wait, with a greatly increased probability of attack attempts. But it will appeal to you emotionally, making you feel better that the vendor got their "feet held to the fire". That ought to make up for the extra time you'll spend implementing the workaround and interfacing with all your users and managers and explaining to them why a service they depend upon (and consider your job to keep operational) is not available temporarily.
In the last several years of using Redhat, and slackware before that, and macintosh OS 6/7 before that, and the apple ][ before that..... I have never, not even once, had to use IE for anything (like Windows Update).
I believe the current "best practice" is to wait at least 1 week for the vendor to initially respond... and to give them at least 1 month to create a patch if they (privately) acknowledge the problem.
But giving them ZERO hours is about as bad as it gets.
But it is send on behalf of companies within the US, selling products targeted at the US market, to US citizens. Make any of these illegal and vigorously enforced, and most of the current spam will stop.
Make it so addresses can not be spoofed, email headers can't be forged and [snip, IP number authentication]. I think if you fixed this, then a lot of the spam would just go away.
The unfortunate obstacle to implementing this is that a good portion of all legitimate email transmitted today is misconfigured, and effective "forges" its sender address. Examples include people who send "from their work address" using their home computer and ISP (no VPN connection to the corporate email server). Likewise for sending as if from yahoo or hotmail, using your ISP rather than having to use the web interface. Sales people and other road warriors often depend on being able to transmit email from within a hotel room or off-site location, using whatever mailserver they can find. "Vanity domain names" are also a big issue, since nearly all of these are hosted by an ISP who simply forwards received messages, and transmitted messages are effectively "forged". There are also a large number of organizations that simply haven't configured outgoing mail properly, sometimes at the server, and more problematically on hundreds or thousands of client machines which all send through some mail server, effectively "forging" their outbound mail.
SPF is the leading effort right now to add simple, IP-number based sender domain name authentication to existing email. (the others were RMX and DMP). SPF allows many different ways (called "mechanisms" in the spec) to check if the transmitting IP number is authorized to send for that domain name. You can read all about it at the SPF site by following that link.
But despite SPF's simplict and backwards compatibility (and the very similar RMX and DMP proposals), there has been massive objection to it. For a truely sad tale of these objections, search for the draft proposals of RMX and scroll to the section near the end about the objections raised. For anyone who believes some technical improvements to adding authentication to SMTP, or replacing SMTP, is a viable solution to stopping spam... reading about the objections in the RMX draft should be a sobering wake-up call and put the enormous inertia of SMTP's forgability into perspective.
Since he didn't discuss his methodology, and admitted not feeding the same stream of messages into all 5 filters, and we know he didn't do much investigage (likely because he's a gui-only guy), it seems pretty likely he ran it on incoming messages for a day, or perhaps only several hours... not long enough for the Bayesian filter to activate.
In mid-September, a rumor was reported that Ford was "considering" a switch for servers. Somehow that turned into a rumor of a massive desktop migration.
A few weeks later, Ford announced they were NOT going to switch desktops to linux (google cache, original article off-line now). Ford specifically mentioned just signing a 3 year contract with Microsoft. Perhaps the rumor was used as legerage to get a better deal from MS, or perhaps it was just the case of wishful thinking and sloppy reporting.
Here's slashdot's coverage with more links. Notice the update, posted several hours later (probably long after most slashdot readers had long since stopped seeing it)... with the link to a newsforge story, aptly titled Ford move to Linux not true (yet). It was all a rumor that got blown out of proportion.
This is simply incorrect.
The host (your PC) queries both drives using the device identify command, and receives a 512 byte clock of information about each device (if each is present).
While it is true that the 2 devices do not send commands to each other, during startup diagnostics, they do communicate with each other on the "PDIAG" line. The google search you gave returns many datasheets that refer to this "IDE handshake" during startup diagnostics, and also have "clocking" somewhere else in the document.
The truth is that the host (PC) controls the clocking for each device. The master device does not control what clock the host chooses for the slave device.
That is why you must have a master even if there is no slave.
There is no such requirement, other than old bioses which do not properly check for a slave device is the master is not present. Virtually all modern bioses check for a slave-only configuration. Also, most modern operating systems will autodetect the hardware, regardless of the bios detection.
This is a question best answered with another question...
Does anyone remember Della Croce, who falsely registered the trademark "linux" and attempted to extort licensing fees from the various companies who were selling cdroms (back then, many people purchased cdrom rather than downloaded ISOs).
At the time, it seems to drag on forever. Ultimately, the patent and trademark office assigned ownership of the registered "linux" trademark to Linus Torvalds.
In 6-7 years from now (based on the assumption SCO will lose or implode in 2004 or 2005), SCO will probably be a long distant memory, and the result will be absolutely no doubt about the validity of the GPL and openness which allows infrigements to be seen... just as today there is absolutely no doubt about the trademark, all thanks to the unscrupulous efforts (now mostly forgotten) Della Croce.
How about Gartner:
Quoting, so in case you don't want to follow that link and leave the comfort of slashdot:
Admittedly, Garner does recommend delaying new high-performance deployments for a few months to see what happens with SCO.
Or how about IDC's August 2003 survey. Again, quoting:
Or perhaps you want to know what IDC really thinks rather than just a survey result. Well, quoting once more (though you could easily follow the link to see this same text):
Notice that this was written only last month. Apparantly they don't think SCO's going to have much impact. Saddly, there any many other IDC documents where you have to pay to even find out their opinion... the abstracts are so generic you don't even get a hint until you pay. But I suppose that's how the stay in business.
Really? Filters perhaps, but certainly not anything fundamental at the protocol level.
The simplest and most backwards compatible approaches under consideration are IP-number-based sender authentication. These don't require any significant changes to SMTP/ESMTP, and they can be adopted gradually and interoperate with systems not yet deploying them. SPF is probably one most likely to be adopted. The basic idea is to provide a mechanism for a receipient to check if the IP number of the transmitting SMTP server is one of the IP numbers authorized to transmit messages for that domain (existing MX records only tell you the IP number which is to receiving incoming messages).
But there has been considerable resistance to even these relatively simple, very compatible, easily implemented ideas.
The ugly truth is that LOTS of legitimate email takes advantage of SMTP's complete lack of sender authentication. Adding even very simple and relatively weak sender authentication is going to create a LOT of pain for everyone with improperly configured outgoing mail, and for message forwarding.
The USA. Well, maybe not exactly 95%, but certainly the vast majority is sent by people in the USA, plugging "products" targeted at US citizens. Spamhaus is currently not responding, otherwise I'd provide a link to the page with their research about the big spammers. They're almost all in the USA.
The fact that messages originate from open relays in Asia does not change the fact that the people responsible for sending those messages are in the US.
What is to stop spammers ... from using this Do-not-spam list as a database
Enforcement of the law. If the law isn't enforced, it won't discourage any of them. But if it is (and we can only hope), and some spammers get a criminal conviction with jail time, it will likely cause other spammers to stop, or move overseas.
We can only hope a number of prosecuters out there have been refraining because there weren't any specific laws and the prospects for putting spammers behind bars were slim. If that changes, we can optimistically hope a number of attorney generals in various states (cough, Florida, cough) will "make an example" out of their state's notorious spammers... and of course make a big public scene about what heros they are for it.
1) He said it's complementary for the duration of your RHN contract and there is a discount available for after that.
No. He said "For those in this position, entitlements to both Red Hat Enterprise Linux ES and WS will be made available for the remainder of the subscriptions". But he did not say you'd get a complementary copy of Enterprise. He did specifically say "discounts are available for Red Hat Enterprise Linux to any RHN customer".
So, if you pay a fee (admittedly discounted) for Enterprise, you can continue using your existing RHN entitlements (which you've already fully paid). If Redhat really is offering current, fully-paid RHN customers a complementary copy of any version of the Redhat Enterprise Linux, please point out where they specifically make such an offer. If you do, I will admit that you were correct and I was mistake. But after re-reading his answers again, and also checking the email I received (I paid for RHN), I have seen no such offer.
He also said Fedora will have a similar up2date utility. But the subject of Fedora's continuance of updates for 2-3 months after subsequent releases was of course not mentioned.
2) Umm, ok, who cares if they don't have a product for small business.
Small businesses probably care. You know, the ones who have found RH9 a good product and until recently believe they could depend on Redhat to continue it.
5) They're still in business, aren't they? The couldn't have made any really big mistakes then.
It is arrogant to refuse to admit ever having made any mistakes. It is foolish to believe they've never made any unwise decisions.
In the dot-com days, sortly after their very successful IPO, Redhat went on a spending spree and purchased several small companies. Not long thereafter, they basically discontinued those products and laid off the employees. One example as HKS, makers of CCVS (credit card verification system), which was open-source. Thanks to Redhat, CCVS no longer exists, and there isn't really an open-source credit card processing software package anymore.
.
But more than any one specific point, Matthew's answers were evasive. He dodged the certral point of most of the questions.
Here's roughly how I read his answers:
1) Your fully paid RHN subscriptions for RH9 will be worthless. You can't have a refund, but you can pay even more for a (discounted but not complementary) upgrade to the enterprise version, to keep using your already-paid RHN entitlements. And yes, we can almost admit the SSL problem that broke RHN was our fault, but rather than appologizing, it was actually due to our excellent security policy.
2) No actual recommendation for small business. Dodge the question by babbling about what a small business is, and something about "Differentiated services skills" during the transition from proprietary to open source deployment. Yeah, sure Roblimo, that's not PR speak! I've got a nice bridge for sale too. Wanna meet in Brooklin to see it?
3) Slashdot readers should be content with Fedora, but everyone who works for a living should pay for various versions of Redhat Enterprise Linux. Non-technical home users should use Microsoft.
4) Redhat decided only to focus on enterprise. Hint that WS is meant to be a client, but ultimately dodge question about advantage of offering "full package" including both desktop and client.
5) Redhat has never made a mistake, even in the dot-com days.
6) Promise to stay with GPL and collaborate with open source community.
7) Hardware support won't come until a large user base demands it. Fedora is supposed to build that user base. Dodge the question about discontinuance of RH9 affecting growth of hardware demand.
8) Shrink wrapped product didn't make enough money and couldn't grow (but no admission it was unprofitable, despite the well-known fact that Redhat was always in the red all those years).
9) Matt user linux and gnome at home.
10) Call us regarding your educational discount... because we won't say anything specific in public.