...but if I were Joe al Q'aeda, with maybe a Bachelor's or a Master's in EE, and me and my friends had taken our annual stipend from the Saudi embassy to build ourselves a nice little EMP weapon and to purchase a van to house it, well, I think you've just told us where we'll be heading...
I'm sure he's not an idiot - he'd probably sample the sound at an appropriate level of compression (which includes none at all), taking into account the age of the soundtrack and consequently the signal-to-noise ratio.
I wish I had your confidence, but I never cease to be amazed at the myriad excuses and [the resulting] myriad techniques people use to cheat on the sound.
And there isn't any technology that can "fool" the eye either.
Artists have known since at least the time of Rembrandt [i.e. almost 400 years] that the human eye can be fooled into seeing what it wants to see; in the case of Rembrandt and his pointilism, the eye [or the part of the brain responsible for processing data collected by the eye] merges small dots of color into a larger whole that it would prefer to see.
I know of no such technique for fooling the human ear. If you run any of these hideous compression technologies through even mid-range audio equipment [at the level of Sony, or Onkyo], you'll be more than aware of what you're missing.
And, while the art of reproducing optical phenomena doesn't even have a popularized concept of "noise," try reproducing ANY sound on ANY electronic device [$100,000 and up] and see if you can get rid of that crackling, hissy sound in the background.
Great, so he's doing optical at 4000 lines per inch.
But what about the sound? Is he using non-compressed 24-bit samples at [at least] 96KSS [kilo samples per second]?
Your ear is a vastly more sophisticated sampling device than your eye; I don't know of a single sound compression technology on the market that can fool the human ear.
It would be a real tragedy to go to all that trouble to make good digital copies of the optical prints, only to try to cheat on storage space by downgrading the soundtracks to one of these abominable undersampled, compressed audio standards.
Allow me to ask it again: What's the state of the art of proofs of parallelizability [and non-parallelizability]?
Is there a standard list of problems that have been proved to be non-parallelizable? Are there any problems that have been proved to be parallelizable, but for which no parallelizing algorithm has yet been discovered? Is there anything analogous to the NP-completeness conjecture in this field?
Allow me to ask it again: What's the state of the art of proofs of parallelizability [and non-parallelizability]?
Is there a standard list of problems that have been proven to be non-parallelizable? Are there any problems that have been proved to be parallelizable, but for which no parallelizing algorithm has yet been discovered? Is there anything analogous to the NP-completeness conjecture in this field?
Which leads to my pondering thought, I wonder if all non-parallel algorithms can be rewritten in a parallel form? For example, I've personally worked the proof that all recursive algorithms can be written as iterative algorithms (and vice versa) as part of my coursework. I've got a gut feeling that the same "equivalence" won't hold for parallel vs serial algorithms, but I'd like to know if it has been formally (dis)proven.
Allow me to ask it again: What's the state of the art of proofs of parallelizability [and non-parallelizability]?
Is there a standard list of problems that have been proven to be non-parallelizable? Are there any problems that have been proved to be parallelizable, but for which no parallelizing algorithm has yet been discovered? Is there anything analogous to the NP-completeness conjecture in this field?
What's the state of the art of proofs of parallelizability [and non-parallelizability]?
Is there a standard list of problems that have been proven to be non-parallelizable? Are there any problems that have been proved to be parallelizable, but for which no parallelizing algorithm has yet been discovered? Is there anything analogous to the NP-completeness conjecture in this field?
Not diskless clients, thin clients. So, they have their own HDDs, but access most applications through the portal. I do not have this deployed, it is just in testing.
Are you gonna try this over 100mbps ethernet, or do you have Gigabit switches? It's certainly an intriguing idea over gigabit [if you've got really good switches with boatloads of RAM], but I'm dubious as to whether these massive modern operating systems and modern applications can be loaded efficiently over 100mbps pipes.
PS: Are your pagefiles [pagefile.sys] gonna be local or on the Citrix server? Similar questions would apply to your profiles [roaming versus local] and your Outlook/Exchange data. These things can be really massive [gigabytes each].
There are people out there who say that there is no legal requirement to pay income tax to the federal government... How these people propose to fund the building of the roads that they will march on in protest is unclear, but it's an interesting case they put forward from a legal point of view.
The roads are supposed to be funded by the gasoline tax, not the income tax.
Now you might point out that almost none of the money in the highway trust fund goes to pay for highways
By and large, it sounds like you're using Citrix as a Portal, which is a perfectly valid approach to network design.
However, you added the following:
Want to deploy that latest update? A few clicks and it is done. Instead of spending an entire day running around to various client machines. MS still gets their licensing fees.
Am I to conclude that you're using drive-less [disk-less] client workstations, and the clients are booting their operating systems off the network from a Citrix box?
Or do your client workstations still have their own hard-drives and their own copies of the operating system?
You have an app that requires a serious amount of computing power, and a bunch of people who use it.... you don't want to buy each one a $40k monster, so you just by one.
Fine, but it sounds like you've taken an App that was designed for single-users, placed it on a Citrix [or Tarantella] box, and tried to force the App [against its nature] to become a multi-user App.
Why not purchase an App that was designed to run on a server in multi-user mode, and run it from the server to begin with? The only reasons I can see to avoid doing that are either
1) You've got some legacy problems, and you can't yet upgrade from the old single-user version of the App [which would be a perfectly valid reason to look to a stop-gap measure like Citrix], or
2) You compared the sums
(COST OF SINGLE USER APP) + (COST OF CITRIX) + (COST OF HARDWARE)
-vs-
(COST OF MULTI-USER APP) + (COST OF SERVER OPERATING SYSTEM) + (COST OF HARDWARE)
and the sum involving Citrix was smaller than the sum involving the multi-user version of the App.
As for the rest of your post about Tarantella, it sounds like you're using Tarantella as a Portal, which is a perfectly valid approach to network design. If indeed Tarantella has morphed into a Portal Services provider, then I've got no problem with that.
Serious question here: What is the purpose of Citrix, Tarantella, pcAnywhere, and the like?
In the way olden days, I heard that a legitimate use of Citrix was to get Windows-ish performance out of x286 hardware. For example, if you had 1,000 users on x286 machines, and brand spanking new x486/Pentium boxes cost $2000 each, then for an upgrade to something capable of running Windows 3.1x or Windows 95, your hardware costs alone would be $2,000,000. Fine. Say five massive Citrix servers, at $100,000 per, servicing two hundred x286 clients each, would run you $500,000, and you'd save $1,500,000 in upgrade costs.
But the scenario I've outlined would have been valid circa 1996. In 2004, we're at the point where hardware is very nearly worthless: You can get a monstrous hardware client for $500, and 1000 X $500 = the $500,000 you'd spend on Citrix. In today's business climate, it's hard to imagine a scenario in which hardware costs are not DWARFED by software & service costs for enterprise systems. I can't think of a modern use for Citrix, Tarantella, or pcAnywhere, unless either
1) You're trying to network-enable a piece of software [such as Microsoft Access] that was never designed for multi-user access [no pun intended] in the first place, or
2) You're trying to cheat on client licenses for enterprise software that WAS designed for multi-user access.
As an example of 1), you might have some single user application that lives solely on a salesman's desktop computer, and when he's on the road, he uses pcAnywhere on his laptop to login remotely to his desktop and fiddle with that piece of single-user software on his desktop that was never designed to support multi-user access in the first place. Yeah, I'll agree that pcAnywhere provides a quick and dirty hack that gets the job done, but good grief: If you start mandating support for these hacks as applied to a broad spectrum of users, it seems to me that the support team is gonna go absolutely insane from the complexity of the thing [not to mention the insecurity of having myriad laptops lying around in airport lounges and hotel bars, each with access to the very heart of your network...].
But what in the world is the purpose of Citrix in this day and age? To host a single copy of WordPerfect or Attachmate at a central location and allow hundreds of users to cheat on client licenses? Or are you using Citrix to cheat Microsoft out of Windows or MSOffice licenses on each of your client workstations? It's just real hard for me to imagine a scenario where you would want to centralize around a solution like that.
Please enlighten me.
PS: Have any of you Citrix guys heard of this thing called Portal Services? Or is the answer: Yeah, we've heard of Portal Services, but the short-term cost of porting [no pun intended] our systems to Portal Services is much less than the short-term cost of a quick and dirty pcAnywhere/Citrix hack, so we're sticking with the quick and dirty hack, plus, because the hack is so insanely complicated, it gives us job security into the foreseeable future...
How is 100MB a "MASSIVE" graphics presentation? When I'm doing an anim built with blender and rendered in povray, it's really really hard to say under 5GB for a 30 second show. 5 minutes really is 50GB (compressed). And you had 100MB? How oh how did you manage to store it all? Hell video caputure for 30 seconds comes out to 2-3 GB.
It was a single wall-sized poster, video boy. That's what Photoshop & Illustrator are designed for - this thing called "2D" [c.f. Adobe PDF and NextSTEP DisplayPostScript/OSX DisplayPDF].
You seem to be implying that IBM took the work done on Project Monterey and contributed it to linux or to another unix.
No, I am implying that IBM entered into a partnership with SCO to produce an operating system and then stuck a knife in SCO's back just as the operating system was being readied for shipment. Project Monterey was peanuts to a company like IBM, but it was everything to SCO.
Frankly either you are very confused, have a grudge, or both.
Nope, just trying to point out that politically correct [in this case, IBM] does not always imply innocent of wrongdoing.
One likely reason for IBM canning Monterey was that IBM decided to proliferate POWER4, rather than go with Itanium in the medium range, and reserve POWER for the very highest ends of the market. The irony of all this is that now IBM are pushing Linux, and canning their own UNIX anyway.
Yes, it is ironic that IBM decided to ditch Itanium. And it's also ironic that AMD's CISC-ish 64-bit architecture is about to blow Intel's EPIC-ish 64-bit architecture right out of the water.
But for SCO, these aren't ironies; they're tragedies*. SCO staked their very existence on the IBM/Monterey/Merced/Itanium product, and IBM raped them.
IBM laughs all the way to the bank; SCO limps into bankruptcy court.
*Time will tell whether EPIC proves to be a tragedy for Intel; early indications are that it just might.
You cannot survive by selling commodities at a premium, except by bullying your clients into paying the extra, and it's a self-defeating strategy. Every Microsoft user is at a competitive disadvantage, and eventually will either switch, or go broke. The argument that Microsoft software gives you a competitive edge is unproven and rather goes against all experience.
I wouldn't write off Windows as a commodity, and I certainly wouldn't assume that Windows doesn't add value.
I just spent a couple of weeks helping an acquaintance put together a massive graphics presentation [the final file was just shy of 100MB] for a professional conference, all done on Apple OSX. Guess what? OSX is an utter and complete piece of crap, at least as far as the end user experience is concerned. Apple was supposed to have the original drag-n-drop experience, but I doubt that current revs of OSX have one-tenth the drag-n-drop capability of recent Microsoft OSes. This deficiency applies even to flagship Apple partners and their ports to OSX, especially Adobe & Photoshop/Illustrator. And lest you flame me as a Microsoft fanboy, I learned to program about ten years ago on an old NeXT slab using Objective C, so I've got a heckuva sentimental attachment to the platform.
But back to my point: You people have used COM/DCOM & its drag-n-drop capabilities for so long that you've simply taken it for granted. While it may utterly suck as a programming paradigm [and, in all seriousness, when you get right down to it, what programming paradigm doesn't utterly suck?], it works for almost all end-users almost all of the time.
OSX is a joke. Linux on the desktop is such a sack of shit that it doesn't even qualify as a joke - it's more like a parody of a joke.
And you guys better watch out for.NET. Yeah, it utterly sucks [like all programming paradigms; see above], but it sucks A WHOLE HELLUVA LOT LESS than the competition it's about to blast right out of the water. Oh, and I'm a long time Novell CNI/CNE, so don't tell me how I don't want Ximian/Mono/SUSE to be a success.
PS: If you think Java doesn't utterly suck, try to JAVAC the following code:
long theArrayLength = GREAT_BIG_HONKIN_LONG_INT;
double [] theArray = new double[theArrayLength];
for(long i = 0; i < theArray.length; i++)
{
theArray[i] = blahBlahBlah(i);
}
Then remind me just why it is that I should be purchasing that brand-spanking new AMD64 platform, not to mention why I should purchase a SPARC-64 platform that costs more than my house?
And while you're at it, remind me why I should start my new object-oriented database with 32-bit languages like SQL [max BLOB at 2^32 bytes] and Java [no support for 64 bit array indexing], as opposed to C# [native 64 bit array indexing] and something like the.NET object persistence initiative?
The tone of your message makes me suspect that you have a large position in SCOX and believe press releases from SCOX instead of well researched facts on Groklaw; for all I know you may work for SCOX.
No interest in SCO, no interest in Intergraph, no interest in Intel, and no interest in IBM [although I worked there briefly about seven years ago, and, for the record, hated every second of every minute of every hour I spent on IBM premises, and hated the very thought of going to work every day].
Just somebody who follows the news.
And perhaps I should emphasize that my comments had nothing to do with the Torvalds-ish aspects of the SCO litigation [other than to have referenced the fact that Richard Stallman is a marxist whose goal is the abolition of private property rights]. Rather, I commented on PROJECT MONTEREY, which was a joint IBM/SCO project to design a next generation x86-ish/IA64-ish/UNIX-ish operating system out of IBM's AIX and SCO's UnixWare.
IBM had no expertise in writing Unix on x86, SCO had tons of expertise in writing Unix on x86, so IBM called in SCO:
IBM inks Unix pact with SCO
Story last modified October 26, 1998, 1:25 PM PST
The new version of Unix, code-named Monterey, will merge with parts of IBM's Unix operating system (called AIX), some of SCO's UnixWare (a popular version of Unix for small businesses), and a bit of Sequent's PTX technology. The OS will run on Intel's 32-bit and upcoming 64-bit processors as well as IBM's Power family of chips. It's expected to reach the market in about 18 months, around the time when Merced is due.
IBM proceeded to rape and pillage SCO's intellectual property portfolio, plant a knife squarely in SCO's back, twist the knife sadistically, sprinkle a little salt in the wound for good measure, and walk out the door with a big shit-eating grin on its face:
COMPLAINT
54. By about May 2001, all technical aspects of Project Monterey had been substantially completed. The only remaining tasks of Project Monterey involved marketing and branding tasks to be performed substantially by IBM.
55. On or about May 2001, IBM notified plaintiff that it refused to proceed with Project Monterey, and that IBM considered Project Monterey to be "dead." In fact, in violation of its obligations to SCO, IBM chose to use and appropriate for its own business the proprietary information obtained from SCO.
UPDATE: CRN Interview: SCO CEO Defends $1 Billion Lawsuit Against IBM
2:57 PM EST Thurs., Apr. 24, 2003
CRN: How much of this stems from Project Monterey? [Project Monterey was a joint venture between IBM, Intel and SCO to produce a Unix-based cross-platform operating system.]
McBride: IBM walked away from Project Monterey, and they told us if we didn't like it, sue us. That took two years out of our life. IBM took chunks out of Monterey, and gave it away. You can find it in Red Hat and SuSE Linux. When IBM pulled out of Monterey, they did it concurrently with moving over to Linux. The heat has been turning up on this for some time.
Everytime you read about SCO and IBM, repeat to yourself: Project Monterey, PROJECT MONTEREY, PROJECT MONTEREY!!! If IBM hadn't screwed SCO in Project Monterey, i.e. if a viable [which is to say, sellable] product had emerged from Monterey, there'd be no SCO litigation.
I think very highly of Japan today. I wouldn't want an event that happened 50 years ago to make me hate them now.
Fine, although, as a matter of semantics, maybe I should note that you said
There was a point in that movie that I *really* hated the Japanese military of that era
rather than
There was a point in that movie that I *really* hated the Japanese military of our current era
I suppose I should state again for emphasis that I see nothing wrong whatsoever with hating the Japanese military of that era, and, while it's probably not a good idea to harbor too much hate for them now, it's also probably not such a bad idea to store away in the not-so-far recesses of your mind a very firm memory of the evil that the Japanese character was capable of committing as recently as 60 years ago.
I know this isn't the politically correct point to make on/., but what happened to Intergraph appears to have been precisely what happened to SCO.
In the early to mid-nineties, Intel was having problems with their next generation CPU architecture, so they called in the guys from Intergraph for some help. Intel then proceeded to steal almost every piece of intellectual property that Intergraph possessed, stuck a knife squarely in Intergraph's back, and walked right out the door.
Fast forward to the late-nineties: IBM was having problems with their next generation UNIX-ish operating system, so they called in the guys from SCO for some help. Their joint venture was called "Project Monterey," and was a make-or-break gamble for a tiny company like SCO, i.e. SCO staked their future on the product that would emerge from the colloboration. IBM then appears [yes, this will have to be determined in a court of law] to have stolen almost every piece of intellectual property that SCO possessed, stuck a knife squarely in SCO's back, and walked right out the door.
There was a time when the/. types who claim to care about "the little guy" would have been appalled at IBM's behavior, but I guess too many people around here have drunk the Richard Stallman/Karl Marx koolaid to give a damn about things like the foundation of a republic under the rule of law.
PS: Back in the day, Intergraph had some awesome technology, but it almost seems as though they were too far ahead of their time to succeed in yesteryear's marketplace. If you enjoy surfing eBay for old hardware, you'll find things like Intergraph Quad-CPU Pentium servers [that's Pentium, NOT Pentium Pro, although they also made Quad-CPU Pentium Pros, as well], huge Intergraph ADC [analog to digital conversion] drafting tabletops for architects & designers, old Intergraph video acceleration cards that are, to this day, competitive with ATI/nVidia/Matrox, etc.
As a result, I found a guy about 25 miles from me who makes a living servicing old Intergraph rigs - he has a small warehouse filled with massive Intergraph 27"+ monitors that must weigh about a ton each. I really wanted [and still want] to get some, but they draw so much amperage that they practically need their own line to the circuit breaker box. [If you're interested, his eBay store is here. No affiliation.]
Slashdot Mirror
Sorry.
I have to pay 3% of the remaining value on the computer to the local county
Good God, where do you live, Soviet Russia?
Yikes!
People around here are damned near ready to go to war over 0.095% per year.
Lameness filter says I have to have some non-whitespace ASCII text in here.
I'm sure he's not an idiot - he'd probably sample the sound at an appropriate level of compression (which includes none at all), taking into account the age of the soundtrack and consequently the signal-to-noise ratio.
I wish I had your confidence, but I never cease to be amazed at the myriad excuses and [the resulting] myriad techniques people use to cheat on the sound.
And there isn't any technology that can "fool" the eye either.
Artists have known since at least the time of Rembrandt [i.e. almost 400 years] that the human eye can be fooled into seeing what it wants to see; in the case of Rembrandt and his pointilism, the eye [or the part of the brain responsible for processing data collected by the eye] merges small dots of color into a larger whole that it would prefer to see.
I know of no such technique for fooling the human ear. If you run any of these hideous compression technologies through even mid-range audio equipment [at the level of Sony, or Onkyo], you'll be more than aware of what you're missing.
And, while the art of reproducing optical phenomena doesn't even have a popularized concept of "noise," try reproducing ANY sound on ANY electronic device [$100,000 and up] and see if you can get rid of that crackling, hissy sound in the background.
Great, so he's doing optical at 4000 lines per inch.
But what about the sound? Is he using non-compressed 24-bit samples at [at least] 96KSS [kilo samples per second]?
Your ear is a vastly more sophisticated sampling device than your eye; I don't know of a single sound compression technology on the market that can fool the human ear.
It would be a real tragedy to go to all that trouble to make good digital copies of the optical prints, only to try to cheat on storage space by downgrading the soundtracks to one of these abominable undersampled, compressed audio standards.
I asked this earlier in the thread: Provably non-Parallelizable?
Allow me to ask it again: What's the state of the art of proofs of parallelizability [and non-parallelizability]?
Is there a standard list of problems that have been proved to be non-parallelizable? Are there any problems that have been proved to be parallelizable, but for which no parallelizing algorithm has yet been discovered? Is there anything analogous to the NP-completeness conjecture in this field?
I asked this earlier in the thread: Provably non-Parallelizable?
Allow me to ask it again: What's the state of the art of proofs of parallelizability [and non-parallelizability]?
Is there a standard list of problems that have been proven to be non-parallelizable? Are there any problems that have been proved to be parallelizable, but for which no parallelizing algorithm has yet been discovered? Is there anything analogous to the NP-completeness conjecture in this field?
Which leads to my pondering thought, I wonder if all non-parallel algorithms can be rewritten in a parallel form? For example, I've personally worked the proof that all recursive algorithms can be written as iterative algorithms (and vice versa) as part of my coursework. I've got a gut feeling that the same "equivalence" won't hold for parallel vs serial algorithms, but I'd like to know if it has been formally (dis)proven.
I asked this earlier in the thread: Provably non-Parallelizable?
Allow me to ask it again: What's the state of the art of proofs of parallelizability [and non-parallelizability]?
Is there a standard list of problems that have been proven to be non-parallelizable? Are there any problems that have been proved to be parallelizable, but for which no parallelizing algorithm has yet been discovered? Is there anything analogous to the NP-completeness conjecture in this field?
What's the state of the art of proofs of parallelizability [and non-parallelizability]?
Is there a standard list of problems that have been proven to be non-parallelizable? Are there any problems that have been proved to be parallelizable, but for which no parallelizing algorithm has yet been discovered? Is there anything analogous to the NP-completeness conjecture in this field?
Now if that wouldn't be a violation of the Commerce Clause, nothing would be.
What'd you do, go and RTFC?
This is /. - you're supposed to misquote Richard Stallman misquoting Karl Marx.
We can't have any of that constitutional bullshit around here.
Not diskless clients, thin clients. So, they have their own HDDs, but access most applications through the portal. I do not have this deployed, it is just in testing.
Are you gonna try this over 100mbps ethernet, or do you have Gigabit switches? It's certainly an intriguing idea over gigabit [if you've got really good switches with boatloads of RAM], but I'm dubious as to whether these massive modern operating systems and modern applications can be loaded efficiently over 100mbps pipes.
PS: Are your pagefiles [pagefile.sys] gonna be local or on the Citrix server? Similar questions would apply to your profiles [roaming versus local] and your Outlook/Exchange data. These things can be really massive [gigabytes each].
There are people out there who say that there is no legal requirement to pay income tax to the federal government... How these people propose to fund the building of the roads that they will march on in protest is unclear, but it's an interesting case they put forward from a legal point of view.
The roads are supposed to be funded by the gasoline tax, not the income tax.
Now you might point out that almost none of the money in the highway trust fund goes to pay for highways
and at that point maybe we might agree that since the happenin' people don't give a damn about the letter of the law, why should we?By and large, it sounds like you're using Citrix as a Portal, which is a perfectly valid approach to network design.
However, you added the following:
Am I to conclude that you're using drive-less [disk-less] client workstations, and the clients are booting their operating systems off the network from a Citrix box?Or do your client workstations still have their own hard-drives and their own copies of the operating system?
You have an app that requires a serious amount of computing power, and a bunch of people who use it.... you don't want to buy each one a $40k monster, so you just by one.
Fine, but it sounds like you've taken an App that was designed for single-users, placed it on a Citrix [or Tarantella] box, and tried to force the App [against its nature] to become a multi-user App.
Why not purchase an App that was designed to run on a server in multi-user mode, and run it from the server to begin with? The only reasons I can see to avoid doing that are either
As for the rest of your post about Tarantella, it sounds like you're using Tarantella as a Portal, which is a perfectly valid approach to network design. If indeed Tarantella has morphed into a Portal Services provider, then I've got no problem with that.Otherwise I'd give you a bump.
Sorry.
Serious question here: What is the purpose of Citrix, Tarantella, pcAnywhere, and the like?
In the way olden days, I heard that a legitimate use of Citrix was to get Windows-ish performance out of x286 hardware. For example, if you had 1,000 users on x286 machines, and brand spanking new x486/Pentium boxes cost $2000 each, then for an upgrade to something capable of running Windows 3.1x or Windows 95, your hardware costs alone would be $2,000,000. Fine. Say five massive Citrix servers, at $100,000 per, servicing two hundred x286 clients each, would run you $500,000, and you'd save $1,500,000 in upgrade costs.
But the scenario I've outlined would have been valid circa 1996. In 2004, we're at the point where hardware is very nearly worthless: You can get a monstrous hardware client for $500, and 1000 X $500 = the $500,000 you'd spend on Citrix. In today's business climate, it's hard to imagine a scenario in which hardware costs are not DWARFED by software & service costs for enterprise systems. I can't think of a modern use for Citrix, Tarantella, or pcAnywhere, unless either
As an example of 1), you might have some single user application that lives solely on a salesman's desktop computer, and when he's on the road, he uses pcAnywhere on his laptop to login remotely to his desktop and fiddle with that piece of single-user software on his desktop that was never designed to support multi-user access in the first place. Yeah, I'll agree that pcAnywhere provides a quick and dirty hack that gets the job done, but good grief: If you start mandating support for these hacks as applied to a broad spectrum of users, it seems to me that the support team is gonna go absolutely insane from the complexity of the thing [not to mention the insecurity of having myriad laptops lying around in airport lounges and hotel bars, each with access to the very heart of your network...].But what in the world is the purpose of Citrix in this day and age? To host a single copy of WordPerfect or Attachmate at a central location and allow hundreds of users to cheat on client licenses? Or are you using Citrix to cheat Microsoft out of Windows or MSOffice licenses on each of your client workstations? It's just real hard for me to imagine a scenario where you would want to centralize around a solution like that.
Please enlighten me.
PS: Have any of you Citrix guys heard of this thing called Portal Services? Or is the answer: Yeah, we've heard of Portal Services, but the short-term cost of porting [no pun intended] our systems to Portal Services is much less than the short-term cost of a quick and dirty pcAnywhere/Citrix hack, so we're sticking with the quick and dirty hack, plus, because the hack is so insanely complicated, it gives us job security into the foreseeable future...
How is 100MB a "MASSIVE" graphics presentation? When I'm doing an anim built with blender and rendered in povray, it's really really hard to say under 5GB for a 30 second show. 5 minutes really is 50GB (compressed). And you had 100MB? How oh how did you manage to store it all? Hell video caputure for 30 seconds comes out to 2-3 GB.
It was a single wall-sized poster, video boy. That's what Photoshop & Illustrator are designed for - this thing called "2D" [c.f. Adobe PDF and NextSTEP DisplayPostScript/OSX DisplayPDF].
You seem to be implying that IBM took the work done on Project Monterey and contributed it to linux or to another unix.
No, I am implying that IBM entered into a partnership with SCO to produce an operating system and then stuck a knife in SCO's back just as the operating system was being readied for shipment. Project Monterey was peanuts to a company like IBM, but it was everything to SCO.
Frankly either you are very confused, have a grudge, or both.
Nope, just trying to point out that politically correct [in this case, IBM] does not always imply innocent of wrongdoing.
One likely reason for IBM canning Monterey was that IBM decided to proliferate POWER4, rather than go with Itanium in the medium range, and reserve POWER for the very highest ends of the market. The irony of all this is that now IBM are pushing Linux, and canning their own UNIX anyway.
Yes, it is ironic that IBM decided to ditch Itanium. And it's also ironic that AMD's CISC-ish 64-bit architecture is about to blow Intel's EPIC-ish 64-bit architecture right out of the water.
But for SCO, these aren't ironies; they're tragedies*. SCO staked their very existence on the IBM/Monterey/Merced/Itanium product, and IBM raped them.
IBM laughs all the way to the bank; SCO limps into bankruptcy court.
*Time will tell whether EPIC proves to be a tragedy for Intel; early indications are that it just might.
You cannot survive by selling commodities at a premium, except by bullying your clients into paying the extra, and it's a self-defeating strategy. Every Microsoft user is at a competitive disadvantage, and eventually will either switch, or go broke. The argument that Microsoft software gives you a competitive edge is unproven and rather goes against all experience.
I wouldn't write off Windows as a commodity, and I certainly wouldn't assume that Windows doesn't add value.
I just spent a couple of weeks helping an acquaintance put together a massive graphics presentation [the final file was just shy of 100MB] for a professional conference, all done on Apple OSX. Guess what? OSX is an utter and complete piece of crap, at least as far as the end user experience is concerned. Apple was supposed to have the original drag-n-drop experience, but I doubt that current revs of OSX have one-tenth the drag-n-drop capability of recent Microsoft OSes. This deficiency applies even to flagship Apple partners and their ports to OSX, especially Adobe & Photoshop/Illustrator. And lest you flame me as a Microsoft fanboy, I learned to program about ten years ago on an old NeXT slab using Objective C, so I've got a heckuva sentimental attachment to the platform.
But back to my point: You people have used COM/DCOM & its drag-n-drop capabilities for so long that you've simply taken it for granted. While it may utterly suck as a programming paradigm [and, in all seriousness, when you get right down to it, what programming paradigm doesn't utterly suck?], it works for almost all end-users almost all of the time.
OSX is a joke. Linux on the desktop is such a sack of shit that it doesn't even qualify as a joke - it's more like a parody of a joke.
And you guys better watch out for .NET. Yeah, it utterly sucks [like all programming paradigms; see above], but it sucks A WHOLE HELLUVA LOT LESS than the competition it's about to blast right out of the water. Oh, and I'm a long time Novell CNI/CNE, so don't tell me how I don't want Ximian/Mono/SUSE to be a success.
PS: If you think Java doesn't utterly suck, try to JAVAC the following code:
Then remind me just why it is that I should be purchasing that brand-spanking new AMD64 platform, not to mention why I should purchase a SPARC-64 platform that costs more than my house? And while you're at it, remind me why I should start my new object-oriented database with 32-bit languages like SQL [max BLOB at 2^32 bytes] and Java [no support for 64 bit array indexing], as opposed to C# [native 64 bit array indexing] and something like theThe tone of your message makes me suspect that you have a large position in SCOX and believe press releases from SCOX instead of well researched facts on Groklaw; for all I know you may work for SCOX.
No interest in SCO, no interest in Intergraph, no interest in Intel, and no interest in IBM [although I worked there briefly about seven years ago, and, for the record, hated every second of every minute of every hour I spent on IBM premises, and hated the very thought of going to work every day].
Just somebody who follows the news.
And perhaps I should emphasize that my comments had nothing to do with the Torvalds-ish aspects of the SCO litigation [other than to have referenced the fact that Richard Stallman is a marxist whose goal is the abolition of private property rights]. Rather, I commented on PROJECT MONTEREY, which was a joint IBM/SCO project to design a next generation x86-ish/IA64-ish/UNIX-ish operating system out of IBM's AIX and SCO's UnixWare.
IBM had no expertise in writing Unix on x86, SCO had tons of expertise in writing Unix on x86, so IBM called in SCO:
IBM proceeded to rape and pillage SCO's intellectual property portfolio, plant a knife squarely in SCO's back, twist the knife sadistically, sprinkle a little salt in the wound for good measure, and walk out the door with a big shit-eating grin on its face: Everytime you read about SCO and IBM, repeat to yourself: Project Monterey, PROJECT MONTEREY, PROJECT MONTEREY!!! If IBM hadn't screwed SCO in Project Monterey, i.e. if a viable [which is to say, sellable] product had emerged from Monterey, there'd be no SCO litigation.Instead, however, IBM threw SCO to the wolves.
I think very highly of Japan today. I wouldn't want an event that happened 50 years ago to make me hate them now.
Fine, although, as a matter of semantics, maybe I should note that you said
rather than I suppose I should state again for emphasis that I see nothing wrong whatsoever with hating the Japanese military of that era, and, while it's probably not a good idea to harbor too much hate for them now, it's also probably not such a bad idea to store away in the not-so-far recesses of your mind a very firm memory of the evil that the Japanese character was capable of committing as recently as 60 years ago.I know this isn't the politically correct point to make on
In the early to mid-nineties, Intel was having problems with their next generation CPU architecture, so they called in the guys from Intergraph for some help. Intel then proceeded to steal almost every piece of intellectual property that Intergraph possessed, stuck a knife squarely in Intergraph's back, and walked right out the door.
Fast forward to the late-nineties: IBM was having problems with their next generation UNIX-ish operating system, so they called in the guys from SCO for some help. Their joint venture was called "Project Monterey," and was a make-or-break gamble for a tiny company like SCO, i.e. SCO staked their future on the product that would emerge from the colloboration. IBM then appears [yes, this will have to be determined in a court of law] to have stolen almost every piece of intellectual property that SCO possessed, stuck a knife squarely in SCO's back, and walked right out the door.
There was a time when the /. types who claim to care about "the little guy" would have been appalled at IBM's behavior, but I guess too many people around here have drunk the Richard Stallman/Karl Marx koolaid to give a damn about things like the foundation of a republic under the rule of law.
PS: Back in the day, Intergraph had some awesome technology, but it almost seems as though they were too far ahead of their time to succeed in yesteryear's marketplace. If you enjoy surfing eBay for old hardware, you'll find things like Intergraph Quad-CPU Pentium servers [that's Pentium, NOT Pentium Pro, although they also made Quad-CPU Pentium Pros, as well], huge Intergraph ADC [analog to digital conversion] drafting tabletops for architects & designers, old Intergraph video acceleration cards that are, to this day, competitive with ATI/nVidia/Matrox, etc.
As a result, I found a guy about 25 miles from me who makes a living servicing old Intergraph rigs - he has a small warehouse filled with massive Intergraph 27"+ monitors that must weigh about a ton each. I really wanted [and still want] to get some, but they draw so much amperage that they practically need their own line to the circuit breaker box. [If you're interested, his eBay store is here. No affiliation.]