If they show code now, they will be demonstrating that they haven't complied with the court's orders.
If you read the (very long) IBM memo, SCO tried this (Sandeep Gupta deposition), and IBM said that and much, much more. Here's basically what IBM said:
SCO's memo was not in format required by law
Gupta's evidence was not filed when required (2 court orders) and now it can't be introduced
Evidence is not from Gupta's personal knowledge
Gupta is not an expert witness
Gupta did not follow required legal required procedure for comparing code
Similarities are only unprotected expression, not copyrightable.
Some code claimed to be similar is not at all alike, even to a untrained viewer (apparantly exhibits attached).
Gupta quoted tiny bits out of context and rearranged them to deceptively make linux and sysv look similar, when the sections quoted aren't similar at all.
Some of the compared code is in the public domain
Much is "scenes a faire" (dictated by compatibility standards and thus not protected by copyright)
Some code Gupta compared is not even part of linux kernel
Gupta only testifies to 300 lines of code, which is not a substantial part of the millions of lines in linux or unix sysv.
If even some of these are true, this last-minute "evidence" doesn't seem like it'll do SCO any good. Then again, we'll know for sure in a couple weeks.
I fully expect to be modded down a bajillion points for making a case for Microsoft here.
Your "case" seems no more than simply wrong "more users -> more bugs" and attempting to shift the blame for bugs to user errors.
Apache runs 67% of all public websites. But somehow that "other" webserver running 20-some percent of sites has fallen victim to numerous remote exploits... including a very nasty one recently that infected a certain popular browser which would in turn infect more of those servers.
The expression "make money off of" seems to have gained a lot of popular usage in recent years. Maybe it's just a harmless common phrase, but every time I see it, I get this dot-com era feeling.
Lacking in this common phrase is a sense that money is being earned. Lacking is a sense of exchange of some tangible goods or valuable service in exchange for the money. Often even an expectation of work performed for or responsibility to customers is absent. Money will simple be made "off of" something... usually intangible intellectual property.
So, dear reader (if you've endured my little rant so far), please keep an eye out for this phrase. Is it usually used in a context devoid of striving to satisfy customers? Or am I just reading to much into it? If so, I'm sure you'll reply to let me know:-)
Wow, you've bought into SCO's position regarding their distribution of GPL'd code.... that it was improperly added by a third party and their subsequent distribution does not obligate them to honor the GPL's terms because they were deceived. Or maybe this subtle is a "devils advocate" thing?
Well, you haven't entirely bought into their twisted logic... you didn't leap to the "GPL is invalid", but rather the GPL's requirements are a "bad idea".
Interesting as this arguement may be, it's a moot point in SCO's case. It's been clearly shown that SCO (then Caldera) was very well aware that the Linux kernel they distributed contained the enterprise-class features in question (NUMA, JFS, etc). They made press releases touting these features. It's also been well documented that SCO's people were involved in contributing some of the disputed code to the kernel, and SCO's management was well aware and approved. All this evidence is very well documented on groklaw.
Even though "tricked into distributing your own proprietary code under the GPL" doesn't apply to SCO, let's take a moment at the core of your arguement:
Now the GPL advocates might want to argue that, nevertheless, the victim of such theft must now either free the code or stop distributing and lose all GPL rights. But IMHO that's a bad idea.
Such a position would greatly hamper the adoption of the GPL codebase by companies with code they wish to keep proprietary - because unknowing propagation of code stolen from them within a large software release (such as a Linux distribution) would leave them on the above cleft stick: Give away your family jewels, or suddenly shut down all your GPL business-model activity.
You believe it's a "bad idea". I disagree.
1: Regarding "greatly hamper the adoption", you're just dead wrong. Take a look around. Adoption of GPL code is progressing very well. Linux is growing dramatically. There's a saying that I believe applies: "if it ain't broke, don't fix it".
2: The primary purpose of the GPL is to ensure freedom to modify and distribute original and modified code. That is why the GPL exists, not to enhance adoption by companies with particular proprietary interests.
The intended effect of ensuring freedom and protecting against proprietary ownership is to build a community where participants collaberate together for their common good. This is the purpose of the GPL. As the community grows, the code is adopted by a wider audience.
In case you haven't noticed, it's working very well. I believe that put the GPL's terms firmly into the category of "good idea".
Regarding the risk of exposure to unintentionally releasing proprietary code under the terms of the GPL... it is a risk. Probably not nearly the risk you make it out to be. Several companies have reached settlements with the FSF (usually over very willful violations of GPL terms). The process has been quite and typical settlements have been very reasonable.
So yes, there is risk in distribution of GPL'd code. Based on history of actions, I believe that risk is relatively minor. Compare that with the risk of incoperating proprietary code. At this point, there are basically two code bases available to implement a unix-compatible operating system. How does the risk of a ugly, expensive, restriction-imposing lawsuit from Linux/FSF/OSI/etc compare with the risk of such a suit from SCO ?
Jump to a a random offset, look for the sync-word, copy a number of frames, repeat... you can jump right to the middle and grab a couple of frames without worrying about the rest.
Expect that mpeg layer 3 audio uses a
bit reservoir, even in constant bitrate encoding (the bits allocated to any one frame of 1152 samples changes).
The IMDCT used by layer 3 also means that the samples out depend on each frame and the previous frame, even if the bit reservoir feature is not in use.
Why doesn't spam come under the same scrutiny and attempts to shut it down as P2P?
As a matter of US federal and state laws, there has been one (admittedly lame) federal law passed to regulate spam, following on the heels of numerous state laws. Yes, the CAN-SPAM act sucks, but it is a law on the books. Compare with p2p, where all proposed bills have died so far.
As a matter of ISP policy, almost all ISPs have anti-spam usage policy. They regularly DO delete accounts abused by spammers. Compare with p2p, where most ISPs allow filesharing and make no attempts to block ports, cancel user accounts, and so on.
As a matter of public awareness/debate/outrage, compare the number of articles regarding spam to p2p... both in tech circles and the mainstream press. Spam certainly is an issue receiving a lot of attention, though it's difficult to find hard numbers to compare to p2p.
As a matter of lawsuits filed against perps, compare the lawsuits launched by AOL, Microsoft, Yahoo and others against numerous spammers to the p2p lawsuits. Ok, here the RIAA is a winner in shear volume of suits against end users.... but to says similar actions aren't being launched against spammers is just not right.
As a matter of effort by individuals and small groups, there are LOTS of people working hard on the spam problem. On the p2p side, there's really nothing like all the individuals who's contributed to blacklists, excellent open source filters like spamassassin, and ideas for protocol improvements (SPF).
All in all, the effort expended against spam far outweights that against p2p. Just because the ultra-high-profile Hollywood interestes are against p2p doesn't mean that p2p is somehow getting more scrutiny than spam.
The only thing that's getting a lot more scrutiny on the p2p side is the back-door lobbying tactics. The scrutiny is well deserved and I hope it continues (will I'm not a fan of p2p apps, the unfortunate trend is to lobby for restrictions far broader than necessary). On the spam side, we just don't have a high profile group lobbying against everyone else's interests.
one day companies might even be willing to pay for part of your handtop
Many companies have tried this with laptops. It almost always ends in frustration.
What would be needed is some sort of dual-boot system or vitualization... where the employee would be free to install games, screensavers and other eye candy, "free" apps that include spyware, and all the other crap that individuals often load onto own computers.... which is entertaining but has a tendancy to interfere with business usage.
As far as most companies are concerned, the potential cost savings of shared ownership ends up being "penny wise, pound foolish" once even a small portion of the employees install software that messes up the machine both makes them unproductive and ties up tech support time from whomever at their company needs to fix it for them.
Actually, in the mid 90's, most unix systems did NOT ship a C compiler. Solaris and HP/UX definately did not. Others shipped a crippled non-ANSI compiler by default. Adding their good ANSI compiler was usually an option for about $2000.
Of course, many people installed gcc rather than paying, and eventually gcc became very widespread.
In any case, if you RTFA, it clearly says that UnixWare comes with a C compiler. Saddly, it isn't mentioned whether it's gcc or which proprietary one it might be.
If someone in the open source / free software community really wanted to put the hurt on SCO, one idea would be to set up a website where current SCO customers desiring low-cost assistance to migrate away from SCO can anonymously post about the scope of the project needed to port their code or adapt their systems.
Advocates wishing to help a SCO customer migrate away could search for projects in their local area, where the work is within their expertise. In the last week or so, at least a few articles have quoted current SCO customers as saying that the cost to port their custom applications is something they haven't budgeted and it will take years to do... only because they need to spread the cost out.
The idea would be to get these smaller and medium size businesses who have old system depending on SCO openserver and unixware in touch with advocates willing to assist at a low cost, for the good cause of helping to put SCO out of its misery.
It's well known that SCO has lost 50% of its sales... and lots of SCO's remaining customers want to migrate away but can't afford it. SCO will gradually lose many of the remaining 50%, but their current plan to raise some cash by selling new versions with new hardware support and open source apps bundled is certain to bring in some money from all these poor folks who are running apps coded for SCO's systems and have likely been stuck with old hardware.
Well, just a pipe dream as far as I'm concerned.... but maybe someone is working on such a thing already, or someone might do such a thing.
Like
Amazon?
Like
Morgan Stanley, Citigroup, and E*Trade?
Like Autozone and DaimlerChrysler?
Like the 60% of all websites, which are powered by open source software? (admittedly, some Apache servers run on commercial unix, freebsd, and some even run on windows).
Yep... a bunch of slashdot obsessed zealots, who only need to....
So I say, it's time to wake up and realize that what this guy is describing is accurate.
Yes, Daniel Lyons is mostly likely accurate in reporting that FACT that SCO claims to have discovered new evidence.
Wether Danial's OPINION, characterizing it as a "smoking gun", turns out to be an accurate remains to be seen. So far, Daniel Lyons, Laura Didio and Rob Enderle have "cried wolf" many times and not once has a so-called "smoking gun" turned out to be of any consequence. Maybe, just maybe, it will turn out to be important. Until then, perhaps you should "wake up and realize" that Danial, Laura and Rob are themselves zealots who've published many alarmist articles about the merits of SCO's case.
Even if SCO finally has found some evidence to support their case... which is a pretty big "if" considering the history of their performance to date, the impact on Linux of a contractual obligation regarding code released in AIX, but not in Linux, remains to be seen.
In the meantime, zealots here on slashdot, on groklaw, and at Forbes, Yankee group and Rob's one-man-show, the Enderle Group will make their predictions.
Let's say a math library that would be used to make calculations to calibrate the weapon. How hard would it be to build in a small tiny bit of error that would only be useful in cases of calibration of high-tech weapons?
Very difficult indeed.
For example, a few years ago, I developed some firmware for a very low cost pressure sensor. It included routines to write results onto a small LCD display. I used a very inexpensive 8 bit microcontroller and I made a lot of very agressive optimizations in assembly language to get the code to fit into a tiny space and use only a few bytes of RAM to convert 24 bit fixed point numbers (in a special, customized numerical format) to the display digits.
To develop this code, I also wrote the rather strange algorithm it used in C and compiled it on linux using gcc. I ran it alongside the C library sprintf and did a strcmp for all 2^24 possible inputs, to find all the places where my very wierd (but extreemly compact in that particular 8-bit assembly language) algorithm produced different output from glibc's sprintf.
After fixing many problems, I would down to only several hundred cases where my output was slightly different from the output of the library. I spent about 1 week (full time, 40 hours) investigating every single different. Several were fixable with simple tweaks that only took a few more instructions in the assembly code.
In a few cases, glibc rounded off differently than I expected. After some searching for literature on the finer points of floating point rounding schemes, I can tell you with confidence that glibc is doing things the right way. That rounding scheme is supposed to statistically average out floating point rounding errors by making making some 0.5000000000 round up and others round down.
In the 2^24 test cases with my funny number system and funky algorithm, this only caused a few to be different from the standard library. But I wanted to get to the bottom of exactly why my code wasn't agreeing with the library. I did, and I verified that the library was correct for use in math intensive applications, and in these few cases the error would be only off by one least significant digit on my little LCD in three of 2^24 cases where the raw data was truely ambigious between the two reading anyway.
My application was only checking my own code, but in the process I would have noticed anything strange in the way floats are converted to base10 (quite a bit of floating point math takes place inside the library).
I'm not the only one. Lots of developers worldwide are working on all sorts of custom applications, including lots of incredibly intensive calculations. Linux is very popular for supercomputer applications, as we've heard on slashdot over and over. There are MANY other developers who would have a good change of noticing even the slightest math library problems.
The one last thing... in the almost 9 years my website has been on the web (originally hosted at a university), I've had dozens of people notice and report bugs in code published on my site, as well as suggest some really interesting ideas for improvements. My site is pretty obscure electronics resources that aren't even usable by most people who don't buy or build custom hardware!
For something so widely distributed and widely used as math libraries on linux, bugs leading to errors in calculations are going to be noticed.
Actually, with modern 3.5 inch drives, spinning the drive down and starting it again is probably rougher that simply leaving it spinning all the time.
While it's spinning, the bearings are the mechanical parts that wear. Seagate was the first mainstream drive with the fuild bearings and even now, their have much lower noise levels than Maxtor, WD, etc. Perhaps lower noise is an indication that less vibration or other energy is dissipated?
In any case, if you look at the hard drive specs, you'll see "start/stop cycles" specified for 3.5 inch drives as a measure of reliability. And it's not a giant number.
With the fluid bearings in late model drives, you're probably a lot better to just leave it spinning all the time.
They can't just "take their money". They already gave it to SCO, and SCO's not giving it back.
Well, they reportedly agreed to give back $13e6 in cash and more in common stock with sell rate limits. But if Baystar is to be believed, the deal fell through
Why prolong the agony looking for a declaratory judgement?
When you believe someone owes you money, but won't pay, what do you do? Sounds like negotiations have fallen apart and Baystar's only recourse is to take it to court.
You fail to explain this, and that's why i'm closer to the mark.
Did that explaination work?
If "your mark" was merely that Baystar invested in a legal attack but was unsatisfied with SCO's ability, then the public record clearly supports you. But if "your mark" involves some notion that Baystar was uninterested in profit and only wanted damage to linux (presumably Microsoft covering expected losses), rather than owning a portion of outrageous per-cpu linux license fees.... well, now would be a time to post some compelling evidence to support an accusation of such malice.
So far, Microsoft's "embrace and extend" has been to include checking the "From" line that end users see, instead of only the envelope data that the mail server sees.
Obviously you don't remember the bad old days of Linux a.out. It's not about the binary applications... it's about the libraries.
Under a.out, each library had to be assigned a memory location. Back in the old days, there was a long list of official assignments that you could download from sunsite and the other major ftp sites. There were three major problems.
New libraries had to obtain an "official" memory range allocation if they were to be distributed to a wide audience. I never compiled any shared libs back then, but I'm sure someone around here must remember who was in charge of the official memory allocation list.
Revisions to a library had to fit within the space they had been allocated. Add too much code, and all of a sudden your shared library may overlap a range reserved for some other library.
Because liberal amounts of extra memory were allocated to each library to allow code size to grow, memory was allocated inefficiently.
By your logic, Apache webservers would be paying the "price of success". In reality, it is Microsoft IIS servers that are suffering security breaches, despite the fact that IIS runs far fewer websites than Apache.
you had to do the following to get infected by any malware:
click one a link
click ok to get rid of any annoying dialog box that pops up warning you about some techno mumbo-jumbo that's too long and complicated to bother reading, and looks a lot like all the other meaningless dialog boxes that always pop up with similar dire warnings.
This statement hardly seems like what's been reported...
Governments don't take well to such practices. When dealing with a state government, you must cross every t and dot every i in the system. Any bugs, flaws or failures is simply delivering a product that wasn't to spec.
Seems like many of the reports so far have shown great support for Diebold at the local and state level. Time and time again, state officials have brushed off complaints and critisms. Even in California, this went on for quite a while. Withness the condition in Florida. The issue is being pressed not be gov't officials, but by grassroots citizen's groups, the ALCU and other non-governmental groups.
Looks who's filing the lawsuit. The plaintifs are Jim March and Bev Harris... activists, not gov't officials. In fact, the lawsuit has been sealed for at least 7 months while the government tried to decide if they wanted to join the plaintifs.
The state of California has STILL not decided if they want to join the plainfits in this lawsuit. That's hardly needing to cross every t and dot event i in the system. It's more a case of needing to hide problems well enough from activists. It's clear the election officials are apathetic and would rather keep any problems swept under the rug than admit they were cheated, purchased shoddy products, and failed to detect accuracy problems.
Slashdot Mirror
If you read the (very long) IBM memo, SCO tried this (Sandeep Gupta deposition), and IBM said that and much, much more. Here's basically what IBM said:
If even some of these are true, this last-minute "evidence" doesn't seem like it'll do SCO any good. Then again, we'll know for sure in a couple weeks.
Your "case" seems no more than simply wrong "more users -> more bugs" and attempting to shift the blame for bugs to user errors.
Apache runs 67% of all public websites. But somehow that "other" webserver running 20-some percent of sites has fallen victim to numerous remote exploits... including a very nasty one recently that infected a certain popular browser which would in turn infect more of those servers.
Yankee Group (Laura Didio)
AdTI (Kevin Brown)
Mindcraft
(Rob) Enderle Group
Forbes (Daniel Lyons)
Maybe they didn't "get away with it", maybe that did. Depends on how you define it.
Except that it is skilled labor positions that are being outsources. Not unskilled manual labor (which was shipped overseas 10-20 years ago).
Lacking in this common phrase is a sense that money is being earned. Lacking is a sense of exchange of some tangible goods or valuable service in exchange for the money. Often even an expectation of work performed for or responsibility to customers is absent. Money will simple be made "off of" something... usually intangible intellectual property.
So, dear reader (if you've endured my little rant so far), please keep an eye out for this phrase. Is it usually used in a context devoid of striving to satisfy customers? Or am I just reading to much into it? If so, I'm sure you'll reply to let me know :-)
Other people critizing the problems is getting tiring....
Just exercising my slashdot-posting pessimism. Mod me down for detracting from the glory of D&D by bringing up this blemish on its good name.
Well, you haven't entirely bought into their twisted logic... you didn't leap to the "GPL is invalid", but rather the GPL's requirements are a "bad idea".
Interesting as this arguement may be, it's a moot point in SCO's case. It's been clearly shown that SCO (then Caldera) was very well aware that the Linux kernel they distributed contained the enterprise-class features in question (NUMA, JFS, etc). They made press releases touting these features. It's also been well documented that SCO's people were involved in contributing some of the disputed code to the kernel, and SCO's management was well aware and approved. All this evidence is very well documented on groklaw.
Even though "tricked into distributing your own proprietary code under the GPL" doesn't apply to SCO, let's take a moment at the core of your arguement:
Now the GPL advocates might want to argue that, nevertheless, the victim of such theft must now either free the code or stop distributing and lose all GPL rights. But IMHO that's a bad idea.
Such a position would greatly hamper the adoption of the GPL codebase by companies with code they wish to keep proprietary - because unknowing propagation of code stolen from them within a large software release (such as a Linux distribution) would leave them on the above cleft stick: Give away your family jewels, or suddenly shut down all your GPL business-model activity.
You believe it's a "bad idea". I disagree.
1: Regarding "greatly hamper the adoption", you're just dead wrong. Take a look around. Adoption of GPL code is progressing very well. Linux is growing dramatically. There's a saying that I believe applies: "if it ain't broke, don't fix it".
2: The primary purpose of the GPL is to ensure freedom to modify and distribute original and modified code. That is why the GPL exists, not to enhance adoption by companies with particular proprietary interests.
The intended effect of ensuring freedom and protecting against proprietary ownership is to build a community where participants collaberate together for their common good. This is the purpose of the GPL. As the community grows, the code is adopted by a wider audience.
In case you haven't noticed, it's working very well. I believe that put the GPL's terms firmly into the category of "good idea".
Regarding the risk of exposure to unintentionally releasing proprietary code under the terms of the GPL... it is a risk. Probably not nearly the risk you make it out to be. Several companies have reached settlements with the FSF (usually over very willful violations of GPL terms). The process has been quite and typical settlements have been very reasonable.
So yes, there is risk in distribution of GPL'd code. Based on history of actions, I believe that risk is relatively minor. Compare that with the risk of incoperating proprietary code. At this point, there are basically two code bases available to implement a unix-compatible operating system. How does the risk of a ugly, expensive, restriction-imposing lawsuit from Linux/FSF/OSI/etc compare with the risk of such a suit from SCO ?
Expect that mpeg layer 3 audio uses a bit reservoir, even in constant bitrate encoding (the bits allocated to any one frame of 1152 samples changes).
The IMDCT used by layer 3 also means that the samples out depend on each frame and the previous frame, even if the bit reservoir feature is not in use.
To "0wn" a computer is to remotely hack in and obtain control.
As a matter of US federal and state laws, there has been one (admittedly lame) federal law passed to regulate spam, following on the heels of numerous state laws. Yes, the CAN-SPAM act sucks, but it is a law on the books. Compare with p2p, where all proposed bills have died so far.
As a matter of ISP policy, almost all ISPs have anti-spam usage policy. They regularly DO delete accounts abused by spammers. Compare with p2p, where most ISPs allow filesharing and make no attempts to block ports, cancel user accounts, and so on.
As a matter of public awareness/debate/outrage, compare the number of articles regarding spam to p2p... both in tech circles and the mainstream press. Spam certainly is an issue receiving a lot of attention, though it's difficult to find hard numbers to compare to p2p.
As a matter of lawsuits filed against perps, compare the lawsuits launched by AOL, Microsoft, Yahoo and others against numerous spammers to the p2p lawsuits. Ok, here the RIAA is a winner in shear volume of suits against end users.... but to says similar actions aren't being launched against spammers is just not right.
As a matter of effort by individuals and small groups, there are LOTS of people working hard on the spam problem. On the p2p side, there's really nothing like all the individuals who's contributed to blacklists, excellent open source filters like spamassassin, and ideas for protocol improvements (SPF).
All in all, the effort expended against spam far outweights that against p2p. Just because the ultra-high-profile Hollywood interestes are against p2p doesn't mean that p2p is somehow getting more scrutiny than spam.
The only thing that's getting a lot more scrutiny on the p2p side is the back-door lobbying tactics. The scrutiny is well deserved and I hope it continues (will I'm not a fan of p2p apps, the unfortunate trend is to lobby for restrictions far broader than necessary). On the spam side, we just don't have a high profile group lobbying against everyone else's interests.
Many companies have tried this with laptops. It almost always ends in frustration.
What would be needed is some sort of dual-boot system or vitualization... where the employee would be free to install games, screensavers and other eye candy, "free" apps that include spyware, and all the other crap that individuals often load onto own computers.... which is entertaining but has a tendancy to interfere with business usage.
As far as most companies are concerned, the potential cost savings of shared ownership ends up being "penny wise, pound foolish" once even a small portion of the employees install software that messes up the machine both makes them unproductive and ties up tech support time from whomever at their company needs to fix it for them.
Of course, many people installed gcc rather than paying, and eventually gcc became very widespread.
In any case, if you RTFA, it clearly says that UnixWare comes with a C compiler. Saddly, it isn't mentioned whether it's gcc or which proprietary one it might be.
Advocates wishing to help a SCO customer migrate away could search for projects in their local area, where the work is within their expertise. In the last week or so, at least a few articles have quoted current SCO customers as saying that the cost to port their custom applications is something they haven't budgeted and it will take years to do... only because they need to spread the cost out.
The idea would be to get these smaller and medium size businesses who have old system depending on SCO openserver and unixware in touch with advocates willing to assist at a low cost, for the good cause of helping to put SCO out of its misery.
It's well known that SCO has lost 50% of its sales... and lots of SCO's remaining customers want to migrate away but can't afford it. SCO will gradually lose many of the remaining 50%, but their current plan to raise some cash by selling new versions with new hardware support and open source apps bundled is certain to bring in some money from all these poor folks who are running apps coded for SCO's systems and have likely been stuck with old hardware.
Well, just a pipe dream as far as I'm concerned.... but maybe someone is working on such a thing already, or someone might do such a thing.
Hmm... supported by said zealots, like....
Like IBM ?
Like HP ?
Like Oracle ?
Like Novell ?
And primarily only used by zealots, like....
Like Amazon?
Like Morgan Stanley, Citigroup, and E*Trade?
Like Autozone and DaimlerChrysler?
Like the 60% of all websites, which are powered by open source software? (admittedly, some Apache servers run on commercial unix, freebsd, and some even run on windows).
Yep... a bunch of slashdot obsessed zealots, who only need to....
So I say, it's time to wake up and realize that what this guy is describing is accurate.
Yes, Daniel Lyons is mostly likely accurate in reporting that FACT that SCO claims to have discovered new evidence.
Wether Danial's OPINION, characterizing it as a "smoking gun", turns out to be an accurate remains to be seen. So far, Daniel Lyons, Laura Didio and Rob Enderle have "cried wolf" many times and not once has a so-called "smoking gun" turned out to be of any consequence. Maybe, just maybe, it will turn out to be important. Until then, perhaps you should "wake up and realize" that Danial, Laura and Rob are themselves zealots who've published many alarmist articles about the merits of SCO's case.
Even if SCO finally has found some evidence to support their case... which is a pretty big "if" considering the history of their performance to date, the impact on Linux of a contractual obligation regarding code released in AIX, but not in Linux, remains to be seen.
In the meantime, zealots here on slashdot, on groklaw, and at Forbes, Yankee group and Rob's one-man-show, the Enderle Group will make their predictions.
Most likely, the capacitive coupling of signals is only targeting chip to chip data signals, not the supply of power to the chips.
Very difficult indeed.
For example, a few years ago, I developed some firmware for a very low cost pressure sensor. It included routines to write results onto a small LCD display. I used a very inexpensive 8 bit microcontroller and I made a lot of very agressive optimizations in assembly language to get the code to fit into a tiny space and use only a few bytes of RAM to convert 24 bit fixed point numbers (in a special, customized numerical format) to the display digits.
To develop this code, I also wrote the rather strange algorithm it used in C and compiled it on linux using gcc. I ran it alongside the C library sprintf and did a strcmp for all 2^24 possible inputs, to find all the places where my very wierd (but extreemly compact in that particular 8-bit assembly language) algorithm produced different output from glibc's sprintf.
After fixing many problems, I would down to only several hundred cases where my output was slightly different from the output of the library. I spent about 1 week (full time, 40 hours) investigating every single different. Several were fixable with simple tweaks that only took a few more instructions in the assembly code.
In a few cases, glibc rounded off differently than I expected. After some searching for literature on the finer points of floating point rounding schemes, I can tell you with confidence that glibc is doing things the right way. That rounding scheme is supposed to statistically average out floating point rounding errors by making making some 0.5000000000 round up and others round down.
In the 2^24 test cases with my funny number system and funky algorithm, this only caused a few to be different from the standard library. But I wanted to get to the bottom of exactly why my code wasn't agreeing with the library. I did, and I verified that the library was correct for use in math intensive applications, and in these few cases the error would be only off by one least significant digit on my little LCD in three of 2^24 cases where the raw data was truely ambigious between the two reading anyway.
My application was only checking my own code, but in the process I would have noticed anything strange in the way floats are converted to base10 (quite a bit of floating point math takes place inside the library).
I'm not the only one. Lots of developers worldwide are working on all sorts of custom applications, including lots of incredibly intensive calculations. Linux is very popular for supercomputer applications, as we've heard on slashdot over and over. There are MANY other developers who would have a good change of noticing even the slightest math library problems.
The one last thing... in the almost 9 years my website has been on the web (originally hosted at a university), I've had dozens of people notice and report bugs in code published on my site, as well as suggest some really interesting ideas for improvements. My site is pretty obscure electronics resources that aren't even usable by most people who don't buy or build custom hardware!
For something so widely distributed and widely used as math libraries on linux, bugs leading to errors in calculations are going to be noticed.
While it's spinning, the bearings are the mechanical parts that wear. Seagate was the first mainstream drive with the fuild bearings and even now, their have much lower noise levels than Maxtor, WD, etc. Perhaps lower noise is an indication that less vibration or other energy is dissipated?
In any case, if you look at the hard drive specs, you'll see "start/stop cycles" specified for 3.5 inch drives as a measure of reliability. And it's not a giant number.
With the fluid bearings in late model drives, you're probably a lot better to just leave it spinning all the time.
They can't just "take their money". They already gave it to SCO, and SCO's not giving it back.
Well, they reportedly agreed to give back $13e6 in cash and more in common stock with sell rate limits. But if Baystar is to be believed, the deal fell through
Why prolong the agony looking for a declaratory judgement?
When you believe someone owes you money, but won't pay, what do you do? Sounds like negotiations have fallen apart and Baystar's only recourse is to take it to court.
You fail to explain this, and that's why i'm closer to the mark.
Did that explaination work?
If "your mark" was merely that Baystar invested in a legal attack but was unsatisfied with SCO's ability, then the public record clearly supports you. But if "your mark" involves some notion that Baystar was uninterested in profit and only wanted damage to linux (presumably Microsoft covering expected losses), rather than owning a portion of outrageous per-cpu linux license fees.... well, now would be a time to post some compelling evidence to support an accusation of such malice.
So far, Microsoft's "embrace and extend" has been to include checking the "From" line that end users see, instead of only the envelope data that the mail server sees.
At least we don't have to worry about "apt-get update" :-)
Under a.out, each library had to be assigned a memory location. Back in the old days, there was a long list of official assignments that you could download from sunsite and the other major ftp sites. There were three major problems.
Obviously, this wasn't scalable.
By your logic, Apache webservers would be paying the "price of success". In reality, it is Microsoft IIS servers that are suffering security breaches, despite the fact that IIS runs far fewer websites than Apache.
Governments don't take well to such practices. When dealing with a state government, you must cross every t and dot every i in the system. Any bugs, flaws or failures is simply delivering a product that wasn't to spec.
Seems like many of the reports so far have shown great support for Diebold at the local and state level. Time and time again, state officials have brushed off complaints and critisms. Even in California, this went on for quite a while. Withness the condition in Florida. The issue is being pressed not be gov't officials, but by grassroots citizen's groups, the ALCU and other non-governmental groups.
Looks who's filing the lawsuit. The plaintifs are Jim March and Bev Harris... activists, not gov't officials. In fact, the lawsuit has been sealed for at least 7 months while the government tried to decide if they wanted to join the plaintifs.
The state of California has STILL not decided if they want to join the plainfits in this lawsuit. That's hardly needing to cross every t and dot event i in the system. It's more a case of needing to hide problems well enough from activists. It's clear the election officials are apathetic and would rather keep any problems swept under the rug than admit they were cheated, purchased shoddy products, and failed to detect accuracy problems.