There is the technology available to avoid spam. Spam blacklists,
Who intentionally issue large netblocks against hundreds of innocent bystanders that just happen to be at the same ISP as a spammer. And who are much better at adding to their lists than removing from them. And who've been largely taken out by illegal DDoS attacks (presumably by the spammers).
Bayesian filters,
Which require training from the user, and over time require the user to retrain by actually checking the filtered spam.
and Challenge-Response systems
That are not a solution for people who WANT to be contacted by legitimate users without presenting a rude "jump through these hoops to prove you're not a spammer, or piss off".
If you left your house door open and somebody entered and made a mess in your house (or worse!) then who is to blame?
Who is at fault?
The intruder.
If you have a lock available to you then you use it. The same thing goes for your emails.
Obviously you've not seen modern spam. About 200/month get though my filters (spamassassin with quite a bit of custom tuning). Many of those are because my threshold is a bit high because I can't accept false positives (who might be a new customer or someone with a legitimate question about material on my website). But many others get through the filter with a low score.
Spammers are putting a lot of work into crafting filter-resistant messages. In the context of your locked door analogy, how would you view that? If I have a high quality lock on my door, and I'm careful to keep it locked, but theives come along and intentionally defeat my lock.... it is also my fault that I didn't have a perfect lock on my door that nobody can pick. Cause spammers today are doing everything they can to defect the filters (locks) that many people have installed.
But locked or not, it's still wrong (and usually illegal) to enter someone's home without permission. And it's certainly illegal to intentionally break into someone's home by defeating the lock on their door.
But if you're a libretarian, maybe you think it ought to be legal to break into homes if you're strong enough to break down the front door or cleaver enough to pick the lock. And of course, it's ok for spammers to forge headers, use deceptive subject lines, impersonate unsuspecting users, intentionally misspell words or make tricky use of whitespace or embed special html tages for no purpose other than to get past filters, all to hock fraudulent scams and questional merchandise.
Call my a pink liberal commie, but I think it ought to be illegal to use such fraudulent, bad-faith tactics. And it's not ok to break into my home, even on the rare occasion when I happen to forget to lock the door!
Even relatively simple improvements have met with huge resistance. For example, consider the SMTP-compatible approach that was recently being worked on my an IETF group. Here's my limited understanding....
Sites with MTAs (mail servers that transmit messages) would add special "reverse MX" DNS records that give a list of all the valid IP numbers for their server. This is slightly different than a normal MX record, but I'm not going into the fine details (which I don't entirely understand anyway).
Upon receiving a message, the receiving server would do a lookup on that special RMX record for the domain in the From: header. If there is a response, the IP number of the connecting MTA must match one of the valid IP numbers which that domain says are its mail servers.
Like any change, it requires many sites to adopt it. But it's fully reverse compatible with existing smpt infrastructure. You'd think such a simple, backwards compatible proposal would be a "no brainer". (this is different from the existing practice of doing a normal mx lookup... see below for a link to the full RMX proposal).
For the sad story of resistance to any changes, no matter how compatible they may be with existing SMPT, start reading at section 12.4 of the
Internet Draft RMX Proposal. This proposal is pretty well written and quite accessible to most people who know a little about SMTP.
For anyone who buys into the "we gotta implement strong crypto/authentication" arguement of the parent post (such as 3-4 moderators who mod'd it up), please take some time to skim through that internet draft... such as section 3 after having read the part at the end about the incredible resistance there has been to even such a very simple and compatible change.
MTA licensing can be based on digital certificates.
Consider the current practice of SSL certificates, required for "secure" web sites.
A small handful of companies have enriched themselves, issuing the certificates. But at $125/year (and up), the cost is high per site. So many sites share a "wildcard" certificate issued to their ISP. Few (if any) ordinary users know to check the certificate before trusting a website's security, so the verification that the receipient of your sensitive info is ambigious. Over time, certification authorities have cut costs, with the result that it's quite easy to get a certification with fake info, and there's virtually no verification after initial issue, despite having to pay nearly full price to renew every year. Worst of all (for the integrity of the system) are newcomers like
GeoTrust who will issue a cert in only minutes with no real verification at all (other than easily faked domain name registry info).
THAT is the sorry state of SSL certification, despite the high price of certs which should be more than enough to cover the costs to truely verifying the identity of every entity. All in all, SSL certs today mean very little... other than enriching a very untrustworthy (Verisign) to the point where they could buy Thawte and obtain a near monopoly.
We use netflix. It's a nice service. We usually kick back on the couch and have a couple drinks. We don't really care about 5.1 sound (the TV has only two speakers). We don't give a damn about extra. With DVD you have to press a button to make the movie actually play, whereas with VHS all we had to do was put put the tape in. But it is nice not having to press buttons to stop and rewind.
Maybe we're the only ones who just simply watch the movie. But I suspect many others also couldn't care less about all that fancy stuff, and simply want to watch the film.
I would like to see a RDP server service on Linux.
X windows has provided this for well over 10 years. In the oldest form, you set the environment variable DISPLAY to the hostname where you want your apps to show up. I used this all the time in 92-95, when computers were slower you actually got better performance this way since one machine ran the app and the other did all the graphic display.
SSH provides for text login AND X11 graphics, so in recent history you can have this secure (try that with Microsoft).
Over the years, there have been several low bandwidth extensions for X... and people are still working on them. However, these don't seem to come "out of the box" on many distributions, so it does require installing some extra stuff. Sorta like installing remote admin tools for windows.
However, having used unix since the late 80's and linux since 94 (just before the 1.0 kernel), the time spent learning the command line and a good scripting language (awk/sed/sh in the old days, perl in these modern times) is a significant investment that will pay itself back many times over and over again. Yes, I know it seems hard, especially if you've "learned" about computers based on a gui-only system like windows, but it does open up a whole new world of possibilities.
Indeed, this happens all too often. About 4 years ago, I used to work at a small company which was acquired by a large giant. For several months, nothing really happened... until they broight in a new controller for accounting. Our company was smallish (about 100 people) and the controller was to be "in charge" of the computing. Perviously, nobody was really making global computing infrastructure decisions, and virtually all computing stuff was handled by a couple consultants.
Of course, the new guy was a "nobody ever got fired for buying IBM... er, Microsoft", so he wanted everything migrated to a "standardized platform". At that point, the comany had 3 servers... one Windows NT, one Novell, and one Linux. The Linux machine didn't really do a lot (DNS, firewall, some other little stuff)... it was the Novell server which had been running for many years and was doing most of the heavy lifting. Likewise, the NT box ran a couple little databases (not the main one for accounting and manufacturing).
Eventually, everything but the firewall migrated to Windows. It was expensive... they bought some very expensive hardware, but that was a minimal cost compared to the dozens of consultants who seemed to live on-site for easily a year, and the resulting dependance of having many more around permanently afterwards. Migrating to Microsoft Exchange was probably the most expensive part where it was a pure platform switch without new functionality. Massive money was also dumped into a new accounting package, but those things are always expensive and we'd limped along for a couple years before the company was sold... since the new owners would want us to use their software of choice (didn't actually turn out that way), and to keep a massive capital-draining software change off the books while negotiating the sale price.
For a couple years, they were determined to replace that linux firewall/router with expensive Cisco equipment.... but it did some fancy things and despite their supposed certifications, they didn't really understand basic TCP/IP routing, subnets, etc (they knew some expensive gui-based firewall that dumbs down the whole process into pictures and drag-and-drop.... or at least that's my cynical view, believing that ipchains/iptables is pretty straightforward it you know what your subnets are).
Windows won, and Linux and Novell lost, not because of cost or performance or any other real-world considerations. It was entirely due to the whim of a corporate guy they shoved into a position at a newly-acquired small company.
However, in the matter of 16500 webservers switching from linux to win2003 (5% of something, but still only 16500 worldwide), these guys who "go with the trend" and want to "standardize" on whatever if fassionable (whatever Gartner is pushing)... they were probably not behind this. Those guys go with the older revs and rarely want to deploy the newest version. Too risky.
I'd guess Microsoft "sold" win2003 to some high-profile hosting providers.
... how exactly did StarOffice fulfill the "XML promise", er... "the huge universe of MS Office documents becomes available for processing by any programmer with a Perl script..."
Did Sun get all those people using MS Office to convert their documents to StarOffice / OpenOffice XML format, which they can't even use with MS Office ?
It just doesn't make sense. Maybe it has something to do with Chewbacca ?
imagine you write an outline in word. file -> export as -> presentation...
Not hard to imagine, since Office has supported this for many years, using OLE, COM, Active-X, and proprietary formats.
XML may be many things, but this has existed for a very long time without XML.
or in access you select some rows and export to a spreadsheet. this is where staroffice stands to beat them.
An even better example. Imagine that, being able to export from Access to Excel. Who woulda' thought? Certainly not all the MS Office users who've been doing this for many years.
This is an even better example of why Star Office and OpenOffice.org will overtake MS Office, as Sun only now bundles a cripple-ware database app, and OpenOffice has none at all.
Re-reading the Register Article yet again, it indeed does not look good for Linux client-side...
Quoting from the article:
.... so you could maybe view the job as being more about
bringing Linux servers into the infrastructure than specifically running Red Hat.
[snip, linux hype]... But presumably there are still going to be Windows clients in there - by coincidence, we note that this quarter Dell will begin saving the company from the legacy diskette drive.
So the dozens of "this is wonderful news" slashdot comments, regarding the notion linux client "exposure", are all just wishful thinking. There is no reason to believe Ford is deploying Linux clients, and these two phrases definately give the impression that this is just a linux server application and Ford's employees using the system will be running IE on Windoze and will never even know (or care) if Linux, Windows, Solaris, HP/UX or some other system is responsible for actually making it all work behind the scenes.
At this point, "the biggest potential threat to Microsoft in the software developer's 28-year history" (Scotsman article) or "serious step forward for Linux in the corp. market" (Register article) is just a lot of hype.
Most Ford employees will never even know Linux is running on the server. Neither will most of Ford's suppliers. Many thousands of Ford emplyees will not suddently be using Open Office and Mozilla and start insisting on others to use open document formats and standard compliant html. And all sorts of other wishful thinking expressed here in these slashdot comments will not come to pass (at least not as a result of Ford's recent decision). All this really means is that Ford will be added to an already long list of well known corporations who decided to deploy Linux server for some specific applications. All the far-flung predictions about how this is some critical turning point for linux adoption, especially on the client side, are just overrated hype.
Does "for its sales systems, human resources, customer relations and infrastructure" really mean any rank-and-file Ford employees will every actually see Linux, KDE or Gnome, and other linux-based stuff.
Or does it just mean they'll be using IE on Windows and some hidden servers they never see will be doing all the back-end processing for their browser-based sales system, human resources and customer relations applications?
Deploying linux server-side is old news, and (after actually reading both articles) I really don't see language that indicates Ford's linux decision is anything but server-side infrastructure. Did I miss the client-side comment that make this "a serious step forward for Linux in the corporate market" ?
.... pull us into court, and wreck our lives witn no proof.
I doubt these 261 individuals will be so lucky as to be confronted with a vacume of proof.
Most likely, the RIAA will have well documented Kazaa search queries and file downloads from a particular IP number. They will also likely have DHCP logs from the defendant's ISP, clearly showing that the defendant was assigned that IP number during the period of time when the infringing material was offered and downloaded. The DHCP logs will likely list the MAC address associated with the defendant's ethernet card.
I'd call that "beyond a reasonable doubt", in the absence of some extordinary circumstances shown by the defendant. Of course, in a civil suit, all that is required is the lesser standard of "a preponderance of the evidence".
The RIAA will likely have plenty of evidence. So call me a Troll, mod this down as flamebait, whatever.... I'm not defending the RIAA, but to say they're filing suit and pulling people into court without any evidence is ignoring the fact that most Kazaa users are easily tracable by their IP number. Sure, the RIAA has done plenty of stupid things, but to believe they have no evidence against individual file shares is pretty seriously underestimating the power of the dark side!
Even if you are so weathly as to employ a number of servants in your home (who will be replaced by robots), to be even remotely on-topic, you would need to be so disconnected from reality as to not notice that the vast majority of households to not have paid employees.
Many someday "true automation will come in communications and monitoring, where the entire house is a cell-phone, the plumbing tells you when it's leaking, and you can watch TV on any wall", but this pie-in-the-sky home automation really has little to do with the economic impact of millions of low-wage workers losing their jobs.
Take a survey of... computer/software engineers... Ask them how long they expect it'll take for computer software to become smarter than 50% of humans. Almost all of them will agree it will happen, in 300 years at the outside.
Only if they believe moore's law will continue, and CPU's will be 2^(300/1.5) times faster by them.
...75 or even just 50 years is a more typical response, though.
Perhaps if Moore's law ("trend" would be better word) continues, so CPU's are 2^(50/1.5) times faster, or 10 billion times more capable than they are today.
While I utterly disagree that machines will become "smarter than 50% of humans" so quickly, I do agree that they will replace the jobs of those humans that soon, while creating new jobs for a much smaller number of more skilled humans to tend to them.
what happens when the DHS begins to use Linux/Solaris/et al
A few days ago, I did a simple test using Mozilla's email client, where I emailed a copy of/bin/ls to myself, to see what Mozilla would do when it received a linux binary executable.
I'm happy to report that I was offered the choice to save it to disk, or to open the data with an application (which I had to choose without a default, and apps handle the binary data as data, not executable code).
When I saved the file to/tmp, the resulting binary was of course byte-for-byte identical to the copy in/bin, but Mozilla did not set the execute permission bit by default. Since I knew the file was ok, I type "chmod 755/tmp/ls", and then I was able to run the executable.
I had to save the file, then locate the file using another application (I used a shell, but many people might perfer a file manager like Konq), and I had to explicitly change the permissions to allow the internet-received data to be able to run and have (non-root) control over my computer.
So, getting back to the original question.... it's safe to say the until linux systems are populated with dangerous email clients, email-virus writers are going to have to try a lot harder to trick users into executing their code!
The only evidence they provide is Blaster and SoBig...[snip]... they could have been prevented easily by more competent sysadmins and informed users.
Well designed systems do not expose RPC control intended only for LANs to internet accessible interfaces, and they do not enable by default these services that very few users will ever need.
Well designed email clients do not allow users to easily execute code. For example, mozilla in linux will only allow you to save an attachment that appears to be code (not run it directly), and attachments are never saved with execute permission set.
So yes, you are correct, that nothing bad would have occured had many millions of end users been aware of these risky capabilities in their software, and actively chosen to not follow the default settings.
Also, had one company not made the incredibly stupid decision to allow any email attachment ending in.exe,.com,.pif,.vbs (and many others) to obtain control over the end user's computer when the user clicks on it and accepts the default choice, then SoBig would have never managed to spread. The sad truth is that they made this stupid design decision many years ago, and time and time again they're refused to disallow executable attachments, despite a many years long history of email-based viruses.
Likewise, this is really no compelling reason to have port 135 listening by default. Smart design it to leave these things off by default, and require the user to enable them if needed..... especially very seldom used services like RPC.
It does appear that Microsoft might finally be learning from their long history of stupid design. But I doubt it's because of the infections. They are finally starting to wake up because of letter like this one, which make a well reasoned arguement that Microsoft's systems just aren't safe for widespread deployment.
Sure, you may disagree. That is your (silly) choice.... but experience has shown that any system will by and large be deployed with its default configuration. Your arguement that it's perfectly fine for to have a horribly dangerous default setting, and expect the burden to be on millions of end users to consciously change the settings and consciously select non-default choices on every potentially malicious piece of network-arrived data they handle is, well, simply an absurd arguement that blindly ignores many years of experience that default settings and choices are the norm.
I have yet to see a single, documented, upheld court decision asserting that these click-throughs are really legally binding.
There was a case that even went through appeals, and it was covered here on slashdot at least once, maybe twice. It was regarding the lack of warranty on some rather expensive project management software with a very bad bug, where is basically added up the costs of a major job incorrectly. The contractor won as the low bidder, because the costs were off by a couple million dollars! Evidence showed that the software vendor knew of the problem for some time, but hadn't fixed it. The vendor argued that the software had no warranty due to the language of the ELUA, and the court agreed and the contractor lost court costs on top of the loss on the job.
...they think somehow that choosing the right jurisdiction with the right judge will net them a win? I.e. Choose a really clueless judge in a really backwards jurisdiction or some such crap like that? Or maybe they already have a judge up their sleeve?
Nope. Looks like
Judge Dale A Kimball isn't going to hand it to them. Follow that like to my previous post today (which is a repost from a few days ago), for links to lots of info about Kimball, and about how he recently ruled against a plaintif in a copyright case, even though the writing was based partly on the plaintif's works, largely because the plaintif had not acted timely and in good faith of mitigate damages.
No, if that is SCO's angle, it won't work... just like every other aspect of this case that's come to light so far.
On every SCO story, invariably someone posts a paranoid concern that
perhaps a clueless judge will be assigned to the case, and rule in
favor of SCO. These are often moderated to +5, which is
quite silly since
Judge
Dale A. Kimball has already be assigned to the case, and we can see
that he's got a reputation for being fair and capable of understanding
cases involving technology.
Groklaw has
very
extensive research on Kimball's history, which is nicely
summarized and easy to read. Every case has links to much more detail. The
overall appearance is that Kimball will probably do the right thing.
Probably most important is
the
Jacobsen vs Hughes
copyright case. Apart from considering much of the material
uncopyrightable historical facts, Judge Kimball was quite unimpressed
by the plaintif's failure to act in a timely manner to mitigate damages.
Quoting from that article:
"Had Jacobsen voiced his disapproval in 1996, Hughes would have had the
opportunity to take the offending material out of the books," Kimball wrote.
"For Jacobsen to wait until three volumes of the series had been published
before voicing his disapproval, when it is clear he had ample opportunity to
let Hughes know of his disapproval as early as 1996, results in extreme
prejudice to Hughes."
Obviously this bodes quite well for IBM and all Linux users. SCO of
course will claim they stopped distribution of linux, but this ruling
at least shows that Judge Kimball isn't likely to be be charmed with
the deplorable way SCO has conducted itself. Kimball's willingness to
consider the writing a separate work, even though a part of it was
loosely based on Jacobsen's also casts quite a shadow over SCO's
chances (assuming the unlikely worst case scenario that SCO has an ace up
its sleeve, rather than the bogus examples we've seen so far). It's
certainly a good sign that Kimball is unlikely to buy SCO expansive
theories about what constitutes a derivitive work.
The groklaw page has examples where Kimball has ruled against big
business, where he's shown competence at handling software intellectual
property disputes (eg, Altiris vs Symantec), and where he's
handled very complex cases.
While nothing is 100% certain going into the courtroom, it is a fact that
the Judge Kimball has been selected to hear this case. His history
shows he's competent, fair, and at least in Jacobsen vs Hughes, he doesn't
tollerate the sort of shenanigans SCO has been pulling!
(yes, -1 redundant... I posted this on the last SCO story.... but the "idiot judge" comments never seem to stop either!)
Slashdot Mirror
Never thought I'd hear ICANN write "there must be a timely, transparent and predictable process".
Who intentionally issue large netblocks against hundreds of innocent bystanders that just happen to be at the same ISP as a spammer. And who are much better at adding to their lists than removing from them. And who've been largely taken out by illegal DDoS attacks (presumably by the spammers).
Bayesian filters,
Which require training from the user, and over time require the user to retrain by actually checking the filtered spam.
and Challenge-Response systems
That are not a solution for people who WANT to be contacted by legitimate users without presenting a rude "jump through these hoops to prove you're not a spammer, or piss off".
If you left your house door open and somebody entered and made a mess in your house (or worse!) then who is to blame? Who is at fault?
The intruder.
If you have a lock available to you then you use it. The same thing goes for your emails.
Obviously you've not seen modern spam. About 200/month get though my filters (spamassassin with quite a bit of custom tuning). Many of those are because my threshold is a bit high because I can't accept false positives (who might be a new customer or someone with a legitimate question about material on my website). But many others get through the filter with a low score.
Spammers are putting a lot of work into crafting filter-resistant messages. In the context of your locked door analogy, how would you view that? If I have a high quality lock on my door, and I'm careful to keep it locked, but theives come along and intentionally defeat my lock.... it is also my fault that I didn't have a perfect lock on my door that nobody can pick. Cause spammers today are doing everything they can to defect the filters (locks) that many people have installed.
But locked or not, it's still wrong (and usually illegal) to enter someone's home without permission. And it's certainly illegal to intentionally break into someone's home by defeating the lock on their door.
But if you're a libretarian, maybe you think it ought to be legal to break into homes if you're strong enough to break down the front door or cleaver enough to pick the lock. And of course, it's ok for spammers to forge headers, use deceptive subject lines, impersonate unsuspecting users, intentionally misspell words or make tricky use of whitespace or embed special html tages for no purpose other than to get past filters, all to hock fraudulent scams and questional merchandise.
Call my a pink liberal commie, but I think it ought to be illegal to use such fraudulent, bad-faith tactics. And it's not ok to break into my home, even on the rare occasion when I happen to forget to lock the door!
Sites with MTAs (mail servers that transmit messages) would add special "reverse MX" DNS records that give a list of all the valid IP numbers for their server. This is slightly different than a normal MX record, but I'm not going into the fine details (which I don't entirely understand anyway).
Upon receiving a message, the receiving server would do a lookup on that special RMX record for the domain in the From: header. If there is a response, the IP number of the connecting MTA must match one of the valid IP numbers which that domain says are its mail servers.
Like any change, it requires many sites to adopt it. But it's fully reverse compatible with existing smpt infrastructure. You'd think such a simple, backwards compatible proposal would be a "no brainer". (this is different from the existing practice of doing a normal mx lookup... see below for a link to the full RMX proposal).
For the sad story of resistance to any changes, no matter how compatible they may be with existing SMPT, start reading at section 12.4 of the Internet Draft RMX Proposal. This proposal is pretty well written and quite accessible to most people who know a little about SMTP.
For anyone who buys into the "we gotta implement strong crypto/authentication" arguement of the parent post (such as 3-4 moderators who mod'd it up), please take some time to skim through that internet draft... such as section 3 after having read the part at the end about the incredible resistance there has been to even such a very simple and compatible change.
Consider the current practice of SSL certificates, required for "secure" web sites.
A small handful of companies have enriched themselves, issuing the certificates. But at $125/year (and up), the cost is high per site. So many sites share a "wildcard" certificate issued to their ISP. Few (if any) ordinary users know to check the certificate before trusting a website's security, so the verification that the receipient of your sensitive info is ambigious. Over time, certification authorities have cut costs, with the result that it's quite easy to get a certification with fake info, and there's virtually no verification after initial issue, despite having to pay nearly full price to renew every year. Worst of all (for the integrity of the system) are newcomers like GeoTrust who will issue a cert in only minutes with no real verification at all (other than easily faked domain name registry info).
THAT is the sorry state of SSL certification, despite the high price of certs which should be more than enough to cover the costs to truely verifying the identity of every entity. All in all, SSL certs today mean very little... other than enriching a very untrustworthy (Verisign) to the point where they could buy Thawte and obtain a near monopoly.
Why would MTA licensing somehow be any better?
Maybe we're the only ones who just simply watch the movie. But I suspect many others also couldn't care less about all that fancy stuff, and simply want to watch the film.
Is that not exactly what they did last Thrusday (Sept 25, 2003), and Bush signed into law this afternoon.
X windows has provided this for well over 10 years. In the oldest form, you set the environment variable DISPLAY to the hostname where you want your apps to show up. I used this all the time in 92-95, when computers were slower you actually got better performance this way since one machine ran the app and the other did all the graphic display.
SSH provides for text login AND X11 graphics, so in recent history you can have this secure (try that with Microsoft).
Over the years, there have been several low bandwidth extensions for X... and people are still working on them. However, these don't seem to come "out of the box" on many distributions, so it does require installing some extra stuff. Sorta like installing remote admin tools for windows.
However, having used unix since the late 80's and linux since 94 (just before the 1.0 kernel), the time spent learning the command line and a good scripting language (awk/sed/sh in the old days, perl in these modern times) is a significant investment that will pay itself back many times over and over again. Yes, I know it seems hard, especially if you've "learned" about computers based on a gui-only system like windows, but it does open up a whole new world of possibilities.
Indeed, this happens all too often. About 4 years ago, I used to work at a small company which was acquired by a large giant. For several months, nothing really happened... until they broight in a new controller for accounting. Our company was smallish (about 100 people) and the controller was to be "in charge" of the computing. Perviously, nobody was really making global computing infrastructure decisions, and virtually all computing stuff was handled by a couple consultants. Of course, the new guy was a "nobody ever got fired for buying IBM... er, Microsoft", so he wanted everything migrated to a "standardized platform". At that point, the comany had 3 servers... one Windows NT, one Novell, and one Linux. The Linux machine didn't really do a lot (DNS, firewall, some other little stuff)... it was the Novell server which had been running for many years and was doing most of the heavy lifting. Likewise, the NT box ran a couple little databases (not the main one for accounting and manufacturing). Eventually, everything but the firewall migrated to Windows. It was expensive... they bought some very expensive hardware, but that was a minimal cost compared to the dozens of consultants who seemed to live on-site for easily a year, and the resulting dependance of having many more around permanently afterwards. Migrating to Microsoft Exchange was probably the most expensive part where it was a pure platform switch without new functionality. Massive money was also dumped into a new accounting package, but those things are always expensive and we'd limped along for a couple years before the company was sold... since the new owners would want us to use their software of choice (didn't actually turn out that way), and to keep a massive capital-draining software change off the books while negotiating the sale price. For a couple years, they were determined to replace that linux firewall/router with expensive Cisco equipment.... but it did some fancy things and despite their supposed certifications, they didn't really understand basic TCP/IP routing, subnets, etc (they knew some expensive gui-based firewall that dumbs down the whole process into pictures and drag-and-drop.... or at least that's my cynical view, believing that ipchains/iptables is pretty straightforward it you know what your subnets are). Windows won, and Linux and Novell lost, not because of cost or performance or any other real-world considerations. It was entirely due to the whim of a corporate guy they shoved into a position at a newly-acquired small company. However, in the matter of 16500 webservers switching from linux to win2003 (5% of something, but still only 16500 worldwide), these guys who "go with the trend" and want to "standardize" on whatever if fassionable (whatever Gartner is pushing)... they were probably not behind this. Those guys go with the older revs and rarely want to deploy the newest version. Too risky. I'd guess Microsoft "sold" win2003 to some high-profile hosting providers.
Did Sun get all those people using MS Office to convert their documents to StarOffice / OpenOffice XML format, which they can't even use with MS Office ?
It just doesn't make sense. Maybe it has something to do with Chewbacca ?
Not hard to imagine, since Office has supported this for many years, using OLE, COM, Active-X, and proprietary formats.
XML may be many things, but this has existed for a very long time without XML.
or in access you select some rows and export to a spreadsheet. this is where staroffice stands to beat them.
An even better example. Imagine that, being able to export from Access to Excel. Who woulda' thought? Certainly not all the MS Office users who've been doing this for many years.
This is an even better example of why Star Office and OpenOffice.org will overtake MS Office, as Sun only now bundles a cripple-ware database app, and OpenOffice has none at all.
So that's 93%, not 91%... as long as we're nit picking over 1024 vs 1000.
- Booze and TOTALLY NAKED women in our strip clubs
Yep, we got that!. Note, most are full bar, but some only have beer/wine, and ALL are full nude.
- Toronto (much like NYC I think) allows women to walk around topless (not that any do, but the possibility is there)
got that too... not just in theory... warning, nudity if you follow that link :-)
- Casinos popping up all over the place
Saddly, every indian reservation has one, wether they want to or not. But I'm not going to link to 'em.
- An increasingly larger separation of Church and State (hence the allowed gay marriages)
Well, we don't have this.
- Better beer
Oh, yeah (far too many to list here)
- Cheaper CDs, DVDs, computer hardware, software, and just about any other form of entertainment
Really, how much is a CDR disc, with that RIAA levy?
- Cheaper medicine
Probably true.
Quoting from the article:
So the dozens of "this is wonderful news" slashdot comments, regarding the notion linux client "exposure", are all just wishful thinking. There is no reason to believe Ford is deploying Linux clients, and these two phrases definately give the impression that this is just a linux server application and Ford's employees using the system will be running IE on Windoze and will never even know (or care) if Linux, Windows, Solaris, HP/UX or some other system is responsible for actually making it all work behind the scenes.
At this point, "the biggest potential threat to Microsoft in the software developer's 28-year history" (Scotsman article) or "serious step forward for Linux in the corp. market" (Register article) is just a lot of hype.
Most Ford employees will never even know Linux is running on the server. Neither will most of Ford's suppliers. Many thousands of Ford emplyees will not suddently be using Open Office and Mozilla and start insisting on others to use open document formats and standard compliant html. And all sorts of other wishful thinking expressed here in these slashdot comments will not come to pass (at least not as a result of Ford's recent decision). All this really means is that Ford will be added to an already long list of well known corporations who decided to deploy Linux server for some specific applications. All the far-flung predictions about how this is some critical turning point for linux adoption, especially on the client side, are just overrated hype.
Or does it just mean they'll be using IE on Windows and some hidden servers they never see will be doing all the back-end processing for their browser-based sales system, human resources and customer relations applications?
Deploying linux server-side is old news, and (after actually reading both articles) I really don't see language that indicates Ford's linux decision is anything but server-side infrastructure. Did I miss the client-side comment that make this "a serious step forward for Linux in the corporate market" ?
I doubt these 261 individuals will be so lucky as to be confronted with a vacume of proof.
Most likely, the RIAA will have well documented Kazaa search queries and file downloads from a particular IP number. They will also likely have DHCP logs from the defendant's ISP, clearly showing that the defendant was assigned that IP number during the period of time when the infringing material was offered and downloaded. The DHCP logs will likely list the MAC address associated with the defendant's ethernet card.
I'd call that "beyond a reasonable doubt", in the absence of some extordinary circumstances shown by the defendant. Of course, in a civil suit, all that is required is the lesser standard of "a preponderance of the evidence".
The RIAA will likely have plenty of evidence. So call me a Troll, mod this down as flamebait, whatever.... I'm not defending the RIAA, but to say they're filing suit and pulling people into court without any evidence is ignoring the fact that most Kazaa users are easily tracable by their IP number. Sure, the RIAA has done plenty of stupid things, but to believe they have no evidence against individual file shares is pretty seriously underestimating the power of the dark side!
Execution of arbitrary code with comprehensive access on virtually all windows systems. That's what's the big deal here.
Microsoft finds a flaw, issues the patches, get coverage from slashdot.
As did the recent Sendmail advisory, the BIND (name server) bug, and an Apache bug (which wan't nearly as serious).
It is a big deal when a "critical" problem is found in any software that's installed on a majority of systems.
I just think that slashdot is often bashing MS products for no reason.
Two factors are at work here....
There has been slashdot "coverage" (applying the term loosly to fit slashdot's "editorial" style) of plenty of Linux/Unix based security problems.
Many someday "true automation will come in communications and monitoring, where the entire house is a cell-phone, the plumbing tells you when it's leaking, and you can watch TV on any wall", but this pie-in-the-sky home automation really has little to do with the economic impact of millions of low-wage workers losing their jobs.
Only if they believe moore's law will continue, and CPU's will be 2^(300/1.5) times faster by them.
Perhaps if Moore's law ("trend" would be better word) continues, so CPU's are 2^(50/1.5) times faster, or 10 billion times more capable than they are today.
While I utterly disagree that machines will become "smarter than 50% of humans" so quickly, I do agree that they will replace the jobs of those humans that soon, while creating new jobs for a much smaller number of more skilled humans to tend to them.
Simply not allowing executable attachments by default and not enabling unnecessary services (RPC) by default would have prevented SoBig and MSBlaster.
No fundamental API changes, just simple good design sense.
A few days ago, I did a simple test using Mozilla's email client, where I emailed a copy of /bin/ls to myself, to see what Mozilla would do when it received a linux binary executable.
I'm happy to report that I was offered the choice to save it to disk, or to open the data with an application (which I had to choose without a default, and apps handle the binary data as data, not executable code).
When I saved the file to /tmp, the resulting binary was of course byte-for-byte identical to the copy in /bin, but Mozilla did not set the execute permission bit by default. Since I knew the file was ok, I type "chmod 755 /tmp/ls", and then I was able to run the executable.
I had to save the file, then locate the file using another application (I used a shell, but many people might perfer a file manager like Konq), and I had to explicitly change the permissions to allow the internet-received data to be able to run and have (non-root) control over my computer.
So, getting back to the original question.... it's safe to say the until linux systems are populated with dangerous email clients, email-virus writers are going to have to try a lot harder to trick users into executing their code!
Well designed systems do not expose RPC control intended only for LANs to internet accessible interfaces, and they do not enable by default these services that very few users will ever need.
Well designed email clients do not allow users to easily execute code. For example, mozilla in linux will only allow you to save an attachment that appears to be code (not run it directly), and attachments are never saved with execute permission set.
So yes, you are correct, that nothing bad would have occured had many millions of end users been aware of these risky capabilities in their software, and actively chosen to not follow the default settings.
Also, had one company not made the incredibly stupid decision to allow any email attachment ending in .exe, .com, .pif, .vbs (and many others) to obtain control over the end user's computer when the user clicks on it and accepts the default choice, then SoBig would have never managed to spread. The sad truth is that they made this stupid design decision many years ago, and time and time again they're refused to disallow executable attachments, despite a many years long history of email-based viruses.
Likewise, this is really no compelling reason to have port 135 listening by default. Smart design it to leave these things off by default, and require the user to enable them if needed..... especially very seldom used services like RPC.
It does appear that Microsoft might finally be learning from their long history of stupid design. But I doubt it's because of the infections. They are finally starting to wake up because of letter like this one, which make a well reasoned arguement that Microsoft's systems just aren't safe for widespread deployment.
Sure, you may disagree. That is your (silly) choice.... but experience has shown that any system will by and large be deployed with its default configuration. Your arguement that it's perfectly fine for to have a horribly dangerous default setting, and expect the burden to be on millions of end users to consciously change the settings and consciously select non-default choices on every potentially malicious piece of network-arrived data they handle is, well, simply an absurd arguement that blindly ignores many years of experience that default settings and choices are the norm.
Really? Like what? Which programs in the last couple years??
It's almost always on the install screen and not in any printed format.
There was a case that even went through appeals, and it was covered here on slashdot at least once, maybe twice. It was regarding the lack of warranty on some rather expensive project management software with a very bad bug, where is basically added up the costs of a major job incorrectly. The contractor won as the low bidder, because the costs were off by a couple million dollars! Evidence showed that the software vendor knew of the problem for some time, but hadn't fixed it. The vendor argued that the software had no warranty due to the language of the ELUA, and the court agreed and the contractor lost court costs on top of the loss on the job.
Nope. Looks like Judge Dale A Kimball isn't going to hand it to them. Follow that like to my previous post today (which is a repost from a few days ago), for links to lots of info about Kimball, and about how he recently ruled against a plaintif in a copyright case, even though the writing was based partly on the plaintif's works, largely because the plaintif had not acted timely and in good faith of mitigate damages.
No, if that is SCO's angle, it won't work... just like every other aspect of this case that's come to light so far.
Groklaw has very extensive research on Kimball's history, which is nicely summarized and easy to read. Every case has links to much more detail. The overall appearance is that Kimball will probably do the right thing.
Probably most important is the Jacobsen vs Hughes copyright case. Apart from considering much of the material uncopyrightable historical facts, Judge Kimball was quite unimpressed by the plaintif's failure to act in a timely manner to mitigate damages. Quoting from that article:
Obviously this bodes quite well for IBM and all Linux users. SCO of course will claim they stopped distribution of linux, but this ruling at least shows that Judge Kimball isn't likely to be be charmed with the deplorable way SCO has conducted itself. Kimball's willingness to consider the writing a separate work, even though a part of it was loosely based on Jacobsen's also casts quite a shadow over SCO's chances (assuming the unlikely worst case scenario that SCO has an ace up its sleeve, rather than the bogus examples we've seen so far). It's certainly a good sign that Kimball is unlikely to buy SCO expansive theories about what constitutes a derivitive work.
The groklaw page has examples where Kimball has ruled against big business, where he's shown competence at handling software intellectual property disputes (eg, Altiris vs Symantec), and where he's handled very complex cases.
While nothing is 100% certain going into the courtroom, it is a fact that the Judge Kimball has been selected to hear this case. His history shows he's competent, fair, and at least in Jacobsen vs Hughes, he doesn't tollerate the sort of shenanigans SCO has been pulling!
(yes, -1 redundant... I posted this on the last SCO story.... but the "idiot judge" comments never seem to stop either!)