I believe that what they are trying to protect is not directly which lines are infringing, but the rest of the code that exists around the pieces that have been shown to be infringing. They are being very careful in exposing the proof that this code exists inside of unixware because they are using the blanket of trade secret to protect their entire source code collection. This does not preclude them necessarily from showing which lines are copied, however I suspect that legal counsel warned them of the thin ice that is the trade secret... once the cat is out of the bag in one area, it becomes harder to enforce the trade secret on other portions... particularly since we're talking trade secret on an entire product. In my opinion, it's sound legal advice.
However, not showing the particulars of the infringement to IBM would be considered counter-productive, except as a standard draw-out tactic by their lawyers to stall. Not necessarily sound legal advice, I'd say, unless you were trying to drive the stock price up, and since the lawyers appear to be paid at least partially on stock as part of the retainer, that seems to be good on the part of both the e-staff of SCO and the lawyers. It's just everyone else who gets screwed in the process:)
Actually, since they are claiming trade secrets apply in this case, it does specifically matter, as they are afforded no other protection on a trade secret but keeping it secret.
And I don't think qt is bad, honestly, regardless of the immediate troll-like backlash I got (not you, but the other person) - but I do think that moc is a pain in the butt for its total ignorance of preprocessor macros.
The problem is EXACTLY that it ignores these things. it ends up building source files that choke because in moc's auto-built sourcefiles it has references to things that don't exist anymore if you're not building for qpe. all because you want to do something simple like use the file selectors that come with qpe instead of rolling your own, so your app looks integrated into the system instead of like bits are tacked on.
apologies for the lack of indentation at all, because slash forms reject nbsp apparently. oh well.
However, all that is in volume 2 is man pages in printed format, for the most part. nothing available in that book (which I also own) that isn't easier to find using the command line.
well, to be fair, moc really is a pain in the behind. the fact that it doesn't let you use any c preprocessor macros for things like header include files make it difficult to support cross compilation for a wide variety of platforms without doing additional non-cpp (auto-tools style) preprocessing, which means you have to forego their make-building utilities... which means that you lose their ease of cross-platform compiling. this is particularly apparent (at least to me) when trying to build a dual mode Qt and Qt/E application, or at least it was when the zaurus first came out.
I highly recommend the X Programming manuals by ORA - particularly volumes 0 and 1. the rest are fluff, imnsho.
volume 1 does contain some documentation about writing a window manager, but it is really insufficient. if you're looking for appropriate documentation on what it should do, you can find the icccm documentation online somewhere (most modern window managers are NOT icccm compliant however)
our synthesizer runs in a very very small fraction of the footprint (memory and disk space) as the AT&T synthesizer. The AT&T synthesizer is also based on earlier work from our CTO (the AT&T synthesizer is ultimately just festival with some other code on top of it)
actually, there are more types than this.
For example, formant synthesis, and HMM synthesis.
Also, festival supports unit selection synthesis (which is what you're calling corpus synthesis - the corpus is just the body of text to be recorded, which is used in diphone synthesis also) as well as diphone synthesis.
You should also check out CMU Flite, which is by one of the guys who built Festival. He also works on other, high quality synthesizers at our company, which you can get demos of at our demo site.
onstar IS to be used to track stolen vehicles. that is part of the appeal. in fact, that's the ONLY purpose to systems like LoJack. since it was used for the intended purpose, it is COMPLETELY acceptable to me that this worked out the way it did
If my car is stolen (equipped with LoJack) and then used in a bank robbery as a getaway vehicle and the cops are looking for it because of my LoJack, that's perfectly acceptable for me. it wasn't their property they were in, they were chased down because of the anti-theft features of someone elses car (which is DESIGNED to catch someone who has stolen your car).
On the flip side, even though I'm sure even though it wouldn't be considered acceptable, if the police knew I had lojack and I was on a high speed persuit and lost them, I'd half-expect them to find me because of my lojack anyways. I'm just glad that me speeding doesn't automatically alert them as I run through their zone.:)
I just went through metamoderation, and I noticed this comment had not only been modded up, but had a lot of people arguing with him... the fact that it's an anonymous coward is irrelevant, but the fact that he linked to a non-existant study (actually it's a link to "From the Source: A Talk with Open Source Advocate Danese Cooper") and he specifically highlighted the words "ugly skank 4-eyes ho" in his comment.... man you guys should at least LOOK before you leap into the flamefest =)
it's all about Cygwin. go to the cygwin site and download and run their setup.exe program... you should pick and choose ssh, openssl, and cvs. that's what I've done to link together the few windows development machines I'm having to use at work with the rest of our development network via cvs. be aware that if you're using something like visual studio, etc, they hold read locks so you have to close the projects / workspaces / etc before cvs will read / write those files.
Cygwin will also set up a bash shell for you. then you can just set all your appropriate environment variables in your.bash_profile, etc, as normal, and use cvs from within the cygwin bash shell. maybe this isn't exactly the solution you were looking for but it's what we've been using here and it seems to work okay.
Slashdot Mirror
damn straight. ;)
But alas I doubt it will have any real effect for several more years.
Oh my, I just noticed the tagline. That made my day. :)
Which is funny, because when I clicked on your homepage from here, it told me that I didn't have permission to read / Error 403
However, not showing the particulars of the infringement to IBM would be considered counter-productive, except as a standard draw-out tactic by their lawyers to stall. Not necessarily sound legal advice, I'd say, unless you were trying to drive the stock price up, and since the lawyers appear to be paid at least partially on stock as part of the retainer, that seems to be good on the part of both the e-staff of SCO and the lawyers. It's just everyone else who gets screwed in the process :)
Actually, since they are claiming trade secrets apply in this case, it does specifically matter, as they are afforded no other protection on a trade secret but keeping it secret.
sounds more like you don't deal well with people than you don't see the use for IM.
Zappa's not dead, he's just working at a burger joint in cleveland with Elvis.
And I don't think qt is bad, honestly, regardless of the immediate troll-like backlash I got (not you, but the other person) - but I do think that moc is a pain in the butt for its total ignorance of preprocessor macros.
Here's an example however:
#ifdef QPE
#include <qpe/filemanager.h>
#include <qpe/fileselector.h>
#endif
No problem yet, until you try to do something in your object definition like...
#ifdef QPE
void openDoc(const DocLnk &doc);
void hideBrowser(void);
#endif
private:
QString filename;
#ifdef QPE
FileSelector *fs;
#endif
The problem is EXACTLY that it ignores these things. it ends up building source files that choke because in moc's auto-built sourcefiles it has references to things that don't exist anymore if you're not building for qpe. all because you want to do something simple like use the file selectors that come with qpe instead of rolling your own, so your app looks integrated into the system instead of like bits are tacked on.
apologies for the lack of indentation at all, because slash forms reject nbsp apparently. oh well.
However, all that is in volume 2 is man pages in printed format, for the most part. nothing available in that book (which I also own) that isn't easier to find using the command line.
well, to be fair, moc really is a pain in the behind. the fact that it doesn't let you use any c preprocessor macros for things like header include files make it difficult to support cross compilation for a wide variety of platforms without doing additional non-cpp (auto-tools style) preprocessing, which means you have to forego their make-building utilities... which means that you lose their ease of cross-platform compiling. this is particularly apparent (at least to me) when trying to build a dual mode Qt and Qt/E application, or at least it was when the zaurus first came out.
volume 1 does contain some documentation about writing a window manager, but it is really insufficient. if you're looking for appropriate documentation on what it should do, you can find the icccm documentation online somewhere (most modern window managers are NOT icccm compliant however)
yes. there is an 0.16.6 release coming out to address this problem actually. I am hoping to have it put out in the next couple of weeks.
Mostly just bugfixes, but also includes some stuff from Kim for running with current desktop hints from gnome/kde.
our synthesizer runs in a very very small fraction of the footprint (memory and disk space) as the AT&T synthesizer. The AT&T synthesizer is also based on earlier work from our CTO (the AT&T synthesizer is ultimately just festival with some other code on top of it)
Also, festival supports unit selection synthesis (which is what you're calling corpus synthesis - the corpus is just the body of text to be recorded, which is used in diphone synthesis also) as well as diphone synthesis.
We've also been doing this for quite some time. you can check out the Cepstral On-Line High Quality Synthesis Demos, as well as our High Quality Limited Domain Demos.
You should also check out CMU Flite, which is by one of the guys who built Festival. He also works on other, high quality synthesizers at our company, which you can get demos of at our demo site.
This sort of technology has been under development for a long time, and we have demos up on our website, also: Cepstral Online Speech Synthesis Demos. In fact, we have Higher Quality Limited Domain Demos available as well.
but I don't think that is relevant here.
onstar IS to be used to track stolen vehicles. that is part of the appeal. in fact, that's the ONLY purpose to systems like LoJack. since it was used for the intended purpose, it is COMPLETELY acceptable to me that this worked out the way it did
If my car is stolen (equipped with LoJack) and then used in a bank robbery as a getaway vehicle and the cops are looking for it because of my LoJack, that's perfectly acceptable for me. it wasn't their property they were in, they were chased down because of the anti-theft features of someone elses car (which is DESIGNED to catch someone who has stolen your car).
:)
On the flip side, even though I'm sure even though it wouldn't be considered acceptable, if the police knew I had lojack and I was on a high speed persuit and lost them, I'd half-expect them to find me because of my lojack anyways. I'm just glad that me speeding doesn't automatically alert them as I run through their zone.
I just went through metamoderation, and I noticed this comment had not only been modded up, but had a lot of people arguing with him... the fact that it's an anonymous coward is irrelevant, but the fact that he linked to a non-existant study (actually it's a link to "From the Source: A Talk with Open Source Advocate Danese Cooper") and he specifically highlighted the words "ugly skank 4-eyes ho" in his comment.... man you guys should at least LOOK before you leap into the flamefest =)
that also doesn't include the overhead for running everything. accounting, travel, etc - all these things add up quickly.
no, actually it's not a bug at all. when you run a shell script, unless you run it like:
. my_shell_script
it in fact runs a completely seperate subshell.
Cygwin will also set up a bash shell for you. then you can just set all your appropriate environment variables in your .bash_profile, etc, as normal, and use cvs from within the cygwin bash shell. maybe this isn't exactly the solution you were looking for but it's what we've been using here and it seems to work okay.