Remember how Win98 was supposed to be the last of the DOS-based OSs?... but then Microsoft couldn't ship Windows 2000 in time, so they threw some extra crap into Win98SE and called it Millennium Edition.
Sounds to me like XP Reloaded is the next Windows Me.
Listen to how they weasel their way into admitting that they implemented the AMD64 instruction set:
Q9: Is it possible to write software that will run on Intel's processors with 64-bit extension technology, and AMD's 64-bit capable processors?
A9: With both companies designing entirely different architectures, the question is whether the operating system and software ported to each processor will run on the other processor, and the answer is yes in most cases. However, Intel processors support additional features, like the SSE3 instructions and Hyper-Threading Technology, which are not supported on non-Intel platforms. As such, we believe developers will achieve maximum performance and stability by designing specifically for Intel architectures and by taking advantage of Intel's breadth of software tools and enabling services.
So, "in most cases, yes" you can write software that will run on both processors (implying that they're implementing AMD64), but be sure to use Intel-specific features such as SSE3 so as to maximize "performance and stability" (i.e., Intel's market dominance).
Disney noted in its statement that it owns rights to all the Pixar movies, as well as two more animated features yet to be delivered -- "The Incredibles" due this year and "Cars", expected in 2005.
Hmm, Pixar does all the work, Disney gets the copyrights. I guess this might have been beneficial years ago when nobody knew who Pixar was, but these days they've made a big enough name for themselves that they don't need to be exploited by a megacorp to be noticed. In fact, Pixar has been responsible for the only good stuff coming out of Disney in the past few years.
The API standards do not define the value of these symbols.
True. But the same values are used for most of the common symbols in many places (including Cygwin, where there's no copyright notice present). Therefore it would be hard for SCO to claim that they have the exclusive right to use that set of numbers.
Even if SCO can prove that the assignment of numeric values to POSIX-specified symbols can be copyrighted in the first place, and that SCO holds a valid copyright to those assignments, SCO is still screwed because SCO's own Linux Kernel Personality module would then be in violation of Linus's copyrights for using the same numeric values as Linux ioctl() #defines, even if they didn't copy any code.
What's more, the same ABIs are used in practically every open-source UNIX, including the BSDs and the "ancient" UNIXes. As well as Cygwin's headers (with no copyright notice present), and even Microsoft's headers as well. It would be mighty hard for SCO to argue that it controls the ABI.
And even if SCO can successfully lay claim to the numbering scheme, then they have a problem, because their own proprietary UNIX offering emulates the Linux ABI. Even if SCO didn't steal any GPL'd code (which is questionable at best), they'd still be infringing Linus's copyrights if their theory were to be upheld.
One of the claims that SCO makes is that the 2.4 kernel and above are the ones with "SCO's IP". So... is there any possibility that a small band of hackers would go back to the 2.2 trees and develop them further or base something new off of those?
This would be an utter waste of time. SCO would just say "We've found our IP in that branch too". Like they did when the 2.6 kernel came out. There is no way out of SCO's crosshairs, since they have no legitimate claim in the first place.
The open source movement simply doesn't appear as a potential source of campaign cash to congressmen, so the likelihood of these dolts being convinced to side with SCO and go against open source software is high.
Fortunately the open source movement has some corporate allies with much more money than SCO will ever hope to have...
I wouldn't get too hot and bothered about it. Sure, most Congresscritters will not understand the issues McBride misrepresents in his missive. But much larger companies than SCO (such as IBM, HP, RedHat, Oracle) will be more than happy to set them straight.
Who do you think contributed more to your representative's campaign? SCO or IBM? Who will they be more inclined to listen to?
This is a publicity stunt designed to pump SCOX stock, nothing more.
First, the lawsuit against Novell,
then, a bunch of interviews,
and now, this ridiculous tripe lobbying congress to ban open source software, when SCO itself still distributes it to this day!
SCO must be trying to distract attention from something. Could it be the hearing scheduled for this Friday?
Keep in mind that the 60+ pages comprises SCO's entire response. There were ten interrogetories SCO was compelled to answer. "List all the infringing code" was just one of those.
Besides, SCO hasn't shown anything credible in several tries so far. I'm betting on more of the same.
Even still, there are two points of fallback:
1. Novell contests ownership of SVR5 copyrights--SCO needs to beat Novell in court before it can succeed against an end user in a copyright infringement claim 2. The BSDi settlement questions whether SVR5 can even be protected by copyright in the first place
I agree with you about TI's complacency.
I'm sure TI makes a tidy profit on their calculators by now, seeing as how their calculator prices have never gone down, and nothing innovative has emerged since the TI 89/92+ in 1998 (which are the same calculator in a different form factor).
One would think they could afford to put in useful upgrades, such as an order of magnitude more RAM or a faster processor (IMHO, 10MHz is laughable these days, even for a graphing calculator).
Then again, perhaps TI sticks with the low-res black-only LCDs, slow processors, and miniscule amounts of RAM to limit power consumption. My TI-89 lasts weeks or months on a set of batteries--you won't get that from a PDA.
The Junior was my first experience with IBM-compatible computing. I had the Extended BASIC cartridge and had a lot of fun programming the Junior's 16-color graphics (vs. the PC's 4-color CGA) and four-note polyphonic sound (vs. the PC's beeper). I was just ten years old at the time and couldn't care less that they were a dismal flop financially--it was a neat little computer in its day.
The chiclet keyboard was a bad idea, but it had a purpose: You could insert overlays showing which key does what for a particular application. Even in its day, though, IBM got enough flak about the chiclet board that they sent all PCjr owners a more normal keyboard free of charge.
I don't think the sidecar alone was the reason for its demise (although not being able to use standard ISA cards certainly contributed to it). The main problem was that it just wasn't compatible enough with the PC, lacking "business" features such as DMA and hard-disk support. And it had a name that was hard to take seriously.
Here is a product that will allow your Linux boxe[n|s] to authenticate with a Windows 2000 Active Directory. We were using it for awhile at my own place of employment, but we stopped when we found that the then-current version didn't work with Windows 2003. I haven't kept up to date with it, however.
Oh, and Vintela happens to be a Canopy Group company, for what that's worth.
IIRC, SCO said they'd graciously allow their vaunted Intellectual Property to be used for educational and noncommercial purposes free of charge. So Universities probably aren't on SCO's hit list. At the moment, at least.
Yet another crippling bombshell hit the beleaguered KDE community when
recently it was learned that UserLinux may not be including their desktop. Coming on the heels of the news of Novell's acquisition of Ximian and then SuSE, a once KDE-centric distro, KDE will lose more market share as SuSE switches to Ximian's GNOME desktop.
You don't need to be a Kreskin to predict KDE's
future. The hand writing is on the wall: KDE faces a bleak future. In fact there won't be any future at all for KDE because KDE is dying.
Why not make the data truly hidden by using the least significant bit within each of the RGB values for a 24 bit color image? 8 bytes of image data can hide 1 byte of data.
If you can repeat the hidden message enough times you might even be able to use this within a jpeg image and have the message survive recompression of the image or slight image manipulation.
Or just use a lossless compression format, such as PNG, or no compression at all (e.g., BMP).
I actually wrote a utility years ago (long before I ever heard of the term "steganography") that would store a secret message in the least significant bits of a true-color BMP file.
Linus commented in the LKML thread that "YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES" (emphasis in original).
I've written a userland program for my company that #includes a single kernel header file (linux/nbd.h, the network block device).
It's mostly of academic interest, since my company has no plans to ship this program, but does #include'ing that GPL'd header file mean that the program must now be GPL licensed?
I didn't think so, since I'm not getting any actual GPL'd code in my own program (just #defines for ioctl() numbers, and a couple of struct definitions), but Linus's comment seems to say otherwise.
The hearing covered the Motions to Compel filed by both IBM and SCO.
The judge granted IBM's motions, forcing SCO to reply within 30 days, but did not rule on SCO's own motion to compel against IBM--that was postponed until Jan 24.
SCO has to show its evidence first--the court will not allow SCO to fish for evidence of IBM's wrongdoing eight months after filing suit.
An alternative method of implementing short + long filenames using B-trees. This does not appear to be the method actually used in VFAT. My guess would be that this is one of the alternatives Microsoft considered during the development of Windows 95 to handle long filenames. This patent does not appear to be relevant.
I didn't read the patent in detail, but it could be relevant to the combination of short and long filenames on NTFS, which is indeed implemented using B-trees.
Not enforcing patent rights for 5-7 years and then having a change of heart doesn't work. If you don't enforce your patent rights through litigation in a timely manner once you're aware they're being violated, you lose those rights.
Sadly, that simply isn't true. Trademarks work that way, but patents do not.
Unisys successfully pulled off just such a stunt with LZW compression as used in GIF files.
The seven cents SCOX gained today are nothing compared with the nearly $2 it lost yesterday.
They're pushing for legislation to *protect* our privacy. At least, in the article linked to the story, they are.
Remember how Win98 was supposed to be the last of the DOS-based OSs? ... but then Microsoft couldn't ship Windows 2000 in time, so they threw some extra crap into Win98SE and called it Millennium Edition.
Sounds to me like XP Reloaded is the next Windows Me.
*shudder*
I wrote it sometime during the fall of 2001; I don't remember exactly when, but it was last updated Jan 23 2002.
Of course, X pagers had been around long before this one... can the public submit prior art to the USPTO and get MS's patent denied?
Listen to how they weasel their way into admitting that they implemented the AMD64 instruction set:
So, "in most cases, yes" you can write software that will run on both processors (implying that they're implementing AMD64), but be sure to use Intel-specific features such as SSE3 so as to maximize "performance and stability" (i.e., Intel's market dominance).
Hmm, Pixar does all the work, Disney gets the copyrights. I guess this might have been beneficial years ago when nobody knew who Pixar was, but these days they've made a big enough name for themselves that they don't need to be exploited by a megacorp to be noticed. In fact, Pixar has been responsible for the only good stuff coming out of Disney in the past few years.
Bad news for Disney. I for one won't miss 'em.
True. But the same values are used for most of the common symbols in many places (including Cygwin, where there's no copyright notice present). Therefore it would be hard for SCO to claim that they have the exclusive right to use that set of numbers.
Even if SCO can prove that the assignment of numeric values to POSIX-specified symbols can be copyrighted in the first place, and that SCO holds a valid copyright to those assignments, SCO is still screwed because SCO's own Linux Kernel Personality module would then be in violation of Linus's copyrights for using the same numeric values as Linux ioctl() #defines, even if they didn't copy any code.
What's more, the same ABIs are used in practically every open-source UNIX, including the BSDs and the "ancient" UNIXes. As well as Cygwin's headers (with no copyright notice present), and even Microsoft's headers as well. It would be mighty hard for SCO to argue that it controls the ABI.
And even if SCO can successfully lay claim to the numbering scheme, then they have a problem, because their own proprietary UNIX offering emulates the Linux ABI. Even if SCO didn't steal any GPL'd code (which is questionable at best), they'd still be infringing Linus's copyrights if their theory were to be upheld.
I wouldn't get too hot and bothered about it. Sure, most Congresscritters will not understand the issues McBride misrepresents in his missive. But much larger companies than SCO (such as IBM, HP, RedHat, Oracle) will be more than happy to set them straight.
Who do you think contributed more to your representative's campaign? SCO or IBM? Who will they be more inclined to listen to?
This is a publicity stunt designed to pump SCOX stock, nothing more.
then, a bunch of interviews,
and now, this ridiculous tripe lobbying congress to ban open source software, when SCO itself still distributes it to this day!
SCO must be trying to distract attention from something. Could it be the hearing scheduled for this Friday?
Sounds like Deep Sleep 9 before they brought in the Dominion.
Keep in mind that the 60+ pages comprises SCO's entire response. There were ten interrogetories SCO was compelled to answer. "List all the infringing code" was just one of those.
Besides, SCO hasn't shown anything credible in several tries so far. I'm betting on more of the same.
Even still, there are two points of fallback:
1. Novell contests ownership of SVR5 copyrights--SCO needs to beat Novell in court before it can succeed against an end user in a copyright infringement claim
2. The BSDi settlement questions whether SVR5 can even be protected by copyright in the first place
One would think they could afford to put in useful upgrades, such as an order of magnitude more RAM or a faster processor (IMHO, 10MHz is laughable these days, even for a graphing calculator).
Then again, perhaps TI sticks with the low-res black-only LCDs, slow processors, and miniscule amounts of RAM to limit power consumption. My TI-89 lasts weeks or months on a set of batteries--you won't get that from a PDA.
The chiclet keyboard was a bad idea, but it had a purpose: You could insert overlays showing which key does what for a particular application. Even in its day, though, IBM got enough flak about the chiclet board that they sent all PCjr owners a more normal keyboard free of charge.
I don't think the sidecar alone was the reason for its demise (although not being able to use standard ISA cards certainly contributed to it). The main problem was that it just wasn't compatible enough with the PC, lacking "business" features such as DMA and hard-disk support. And it had a name that was hard to take seriously.
Oh, and Vintela happens to be a Canopy Group company, for what that's worth.
IIRC, SCO said they'd graciously allow their vaunted Intellectual Property to be used for educational and noncommercial purposes free of charge. So Universities probably aren't on SCO's hit list. At the moment, at least.
I believe he's referring to the NEC V20 CPU, which is compatible with the 8086.
Yet another crippling bombshell hit the beleaguered KDE community when recently it was learned that UserLinux may not be including their desktop. Coming on the heels of the news of Novell's acquisition of Ximian and then SuSE, a once KDE-centric distro, KDE will lose more market share as SuSE switches to Ximian's GNOME desktop. You don't need to be a Kreskin to predict KDE's future. The hand writing is on the wall: KDE faces a bleak future. In fact there won't be any future at all for KDE because KDE is dying.
Or just use a lossless compression format, such as PNG, or no compression at all (e.g., BMP).
I actually wrote a utility years ago (long before I ever heard of the term "steganography") that would store a secret message in the least significant bits of a true-color BMP file.
...that include Linux kernel header files?
Linus commented in the LKML thread that "YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES" (emphasis in original).
I've written a userland program for my company that #includes a single kernel header file (linux/nbd.h, the network block device).
It's mostly of academic interest, since my company has no plans to ship this program, but does #include'ing that GPL'd header file mean that the program must now be GPL licensed?
I didn't think so, since I'm not getting any actual GPL'd code in my own program (just #defines for ioctl() numbers, and a couple of struct definitions), but Linus's comment seems to say otherwise.
The hearing covered the Motions to Compel filed by both IBM and SCO.
The judge granted IBM's motions, forcing SCO to reply within 30 days, but did not rule on SCO's own motion to compel against IBM--that was postponed until Jan 24.
SCO has to show its evidence first--the court will not allow SCO to fish for evidence of IBM's wrongdoing eight months after filing suit.
I didn't read the patent in detail, but it could be relevant to the combination of short and long filenames on NTFS, which is indeed implemented using B-trees.
Sadly, that simply isn't true. Trademarks work that way, but patents do not.
Unisys successfully pulled off just such a stunt with LZW compression as used in GIF files.