This guy is not building a gaming platform. He's building a cable decoder.
Cable companies would like nothing more than to rent you immersive, persistent entertainment. ("Sell? That's so last millennium.") Problem: Cable boxes today are pitifully stupid due to the drive to keep costs low; they have no local storage. Also, they've learned the hard way, both through their spastic "Interactive TV" initiatives and their broadband internet offerings, that there's no way they can serve interactive games without intolerable download waits from the head end.
What they want is a PC that the subscriber can't modify in any way. It looks like the Phantom guys propose to build this.
Or, they could just be a bunch of flakes out to put over an obvious hoax on the industry. (Please support our "phantom" console, ha ha...)
"Mr, Simpson, as you may recall during my school-wide address on Tuesday and Friday, all students were strongly encouraged to attend the school's homecoming football game."
"And?"
"And, there is no evidence of your presence in our RFID tracking records."
"I TiVo'ed it off public access cable."
"As I outlined in my address, that was not an acceptable form of team support."
"What's the big deal? It's just a crummy football game."
"Mr. Simpson, the value of a proper display of school spirit cannot be overemphasized. Failure to exhibit such spirit can have serious repercussions."
"You mean like what happened with Ralph Wiggum and the Christmas lights?"
<FLASHBACK>
"Mr. Skinner, I must protest. Dissent is central to a functioning democratic republic."
"Except this isn't a democratic republic, Ralph. It's a public school. My school. And you'll learn to love it here."
"But such treatment is clearly impermissible under the Eighth Amendment's proscription against cruel and unusual pubishment."
Use that one ID in turn to replace your SSC, Green Card, and Passport, an voila, less papers to keep tracked of, a national ID card, and perhaps some money saves(unlikely), in one fell swoop.
Wonderful. And only one document to lose or have stolen to deprive you of the right to drive, right to earn wages, right to be in the country, and right to travel. And probably also loss of your right to access to your money.
Oh, and proving who you are to get a replacement ID card becomes next to impossible, since all forms of corroborative identifaction have been supplanted by the One True ID.
Whether the government does it or private industry, it's a bad idea.
While the Japanese nuclear "industry" is one of the worst in the world in terms of safety, it's impressive that reactors are this small, [... ]
Sony today announced it's latest line of personal entertainment products that, miraculously, don't need batteries, ever. Say hello to the new Sony NukeMan.
WARNING: RADIOLOGICAL HAZARD. DO NOT OPEN; NO USER-SERVICEABLE PARTS INSIDE. IF DEVICE BECOMES OVERLY WARM, IMMERSE IMMEDIATELY IN HEAVY WATER AND CALL THE U.S. ENVIRONMENTAL PROTECTION AGENCY'S RADIOLOGICAL EMERGENCY RESPONSE TEAM. DO NOT USE WHILE PREGNANT OR NURSING AN INFANT. DOES NOT CONFER SUPER-POWERS UPON USER. KEEP AWAY FROM EASILY-MUTATED ARACHNIDS.
Available in red, purple, pink, sky blue, and glow-in-the-dark green.
A true scsi 320 fujitsu 36 gigger is less tahtn 155 bucks [... ]
Yes, but you must concede that this level of affordability is comparatively recent. As little as two years ago, you were paying more than that for 18G drives. And you must further concede that, for the same number of dollars, you'll get an IDE drive that's three times larger. And believe me, if you're at all a gamer, you can fill up 36G with remarkable speed.
Schwab
Fellow SCSI Bigot
P.S: Where are you finding PCI-X SCSI-320 controllers for under $200? Obviously these aren't Adaptecs...
But the lethal stake through the heart of The UNIX-Hater's Handbook's underlying thesis -- namely, that UNIX sucks -- is the unarguable fact that UNIX is still here.
After further thought, it seems I need to repudiate my own post:
The fact that UNIX is still here doesn't necessarily prove anything about the technical merits (or not) of UNIX.
I've been a UNIX user for two decades, and I enjoy it. However, I, too, have used "better" systems. A quick Google for 'ewhac' will reveal many, many posts by a past version of me extolling the virtues of the Amiga with great fervor. Amiga's basically dead now, through no fault of its technology or the imagination of its developers.
Despite the fact that I'm constantly amazed at the new hoops UNIX jumps through (embedded on PDAs?!!?), I'm still of the opinion that UNIX is big, heavy, and slow. UNIX, IMHO, would be a laughable choice for a gaming console (but so also would Windows-NT, and it seems I'm wrong about that, too). However, for a stable development and general purpose computing environment, I find UNIX a comfortable environment.
The point I was trying to make, perhaps with more bombast than was strictly necessary, is that, while UNIX does have flaws, I don't regard The UNIX-Hater's Handbook as an authoratative reference on the subject. The work discredits itself in my eyes by reading too much like a USENET flame.
The book 'invoked' was written by people more highly accredited than you can ever hope to be.
And repudiated by people equally if not more highly accredited. Or did you skip over the Anti-Foreword entirely?
I confess, I have not read The UNIX-Hater's Handbook cover to cover. I found a copy laying around, picked it up and read two or three pages at random. The pages I read were discrediting the curses(3) API for the fact that curses was a link library, not a shared library, and couldn't be transparently upgraded, thereby allowing apps to support new terminal types as support became available. This was presented as an indicative UNIX shortcoming. However, it relies heavily on the reader's lack of knowledge of UNIX history; curses was first developed before UNIX had shared libraries at all. Obviously, a shared library would have been superior, but they did not at that time exist. Should curses then have never been written, because link libraries, "suck?" Once UNIX got them, curses quickly became a shared library. "Problem" solved.
I made the presumption, perhaps inaccurately, that the rest of the book was like this -- a series of disingenuous arguments easily punctured by anyone with a reasonable historical and technical background. If so, the book merits no more attention than your typical USENET flamewar.
But the lethal stake through the heart of The UNIX-Hater's Handbook's underlying thesis -- namely, that UNIX sucks -- is the unarguable fact that UNIX is still here. The history of forces that have tried to kill UNIX in favor of something "better" are, in large part, studies of unsurpassing hubris. Microsoft -- the largest software company on the planet, with the "most talented" engineers on the planet (mostly by fiat, it would seem) -- has devoted major efforts to kill UNIX, first with OS/2, and then with Windows-NT derivatives. They have failed. Indeed, UNIX -- through Linux and BSD variants -- has only gotten stronger.
To cite The UNIX-Hater's Handbook as some sort of reference on bad software design shows little more than an appeal to a demonstrably false authority. UNIX is still here, and there is no indication it's going anywhere soon. The humble student will discover this is not accidental. There's a reason for this.
I think that the unix hater's handbook had a better perspective on unix, and people who become unix 'gurus' [... ]
It is not about what is the best tool for the job, or uses the best methodology, it's simply about who can put out the most smoke-and-mirrors bullshit to convince people that they know fuck-all when they often times [such as your typical slashdotter] don't.
Oh, how very droll.
Your first paragraph invokes a book written in no small part by Microsoft apologists. Your second describes sins committed largely by... Microsoft.
Is there a way to install and run it without having to install the rest of his daemon management stuff? I like to disrupt as few things as possible when making changes to my gateway.
I attended the Vintage Computer Fair and found myself wondering aloud: Why can't software development be as simple as it was back when these machines were state of the art?
To get a program running on a C-64, you simply typed in:
10 PRINT "HELLO, WORLD!"
20 GOTO 10
RUN
And that was it! Real programming, available instantly.
Now, to write a program that employs Best Practices, you need to write code that:
Opens the requisite shared libraries,
Opens the window,
Attaches a menu strip,
Attaches sub-menus, if any, to the menu strip,
Opens the user's default font,
Calculates font metrics and resizes the window/menus to adjust,
Obtains the "Hello, World" string from the resource fork (you want this to be localizeable, right?),
Select the rendering pen color and drawing modes,
Move the pen to the baseline- and kerning-adjusted starting location,
Call DrawText() (or whatever) to render the string,
Spin on the event queue, processing Standard System Messages in the appropriate manner,
Exit the program when the WINDOW_CLOSE event shows up.
And that doesn't include the whole compile-test-debug cycle. I mean, gah!. Programming is supposed to be simple. Just creating the skeleton framework for a simple app can take most of an afternoon, by which time the simple idea you just wanted to try out has lost its charm. Widget toolkits can shield you from only so much -- and they typically insulate you from some things you eventually find you don't want to be insulated from.
Computers have gotten a whole heck of a lot more powerful, but the number of details a programmer needs to keep track of has gone up by at least an order of magnitude.
I did some extensive work in stereoscopy in the late 1980's, so I know a little bit about this. Basically what Sharp is using is a lenticular grille.
The key to stereoscopy is to feed different images to each eye. The brain interprets the parallax difference as depth. To see this sort of thing for yourself, close one eye, and hold two pencils vertically so that they line up one behind the other. Now switch eyes. The pencils appear to have "moved," and no longer appear lined up. This is because your other eye is in a different location, and sees from a different point of view ("duh"). This parallax separation in the left/right images is what triggers depth perception in the brain.
Okay, great, how do you get this on a computer display without funky glasses? Well, to use the pencils you already have, imagine that the farther pencil is the actual LCD pixel element, and the nearer pencil is a black band on a piece of glass/plastic in front of the pixel. One of your eyes cannot see the farther pencil, but the other one can. You have achieved a form of image separation without glasses.
Now, repeat across the entire horizontal display. Your left eye, being shifted slightly to the left, will see all the even-numbered pixel columns; and your right eye, being located slightly to the right, will see all the odd-numbered pixel columns. Result: Sufficient image separation to display and perceive steroscopy.
Problem: The optimum viewing location is fixed. You can be no closer or farther away than the prescribed location, or the images will bleed together or invert at the edges. Also, if your eyes are not centered, the lenticular grille will be effectively shifted relative to the pixel columns, and you'll experience stereo inversion (left and right images swapped; always good for a headache).
If you want to experiment with this stuff at home, and if you have access to a laser printer that will print on transparencies, print up for yourself a transparency with evenly spaced vertical lines, each one pixel in width -- one pixel width black, one pixel width clear, alternating. Lay this over your laptop screen and compose an image with alternating imagery in the odd/even pixel columns. Fun for the whole family!
I just checked the filesize on this mod: 277 mebibytes. WTF?? I have a fairly fat pipe going to my house, but since when did it become a good idea to create demos and/or mods regularly exceeding 100 megs?
I recently downloaded the demo for Tron 2.0, weighing in at about 200 megs. Now, I might almost think this reasonable if it weren't for a few crucial facts:
The demo only included three maps,
There were only three or four enemy models,
Tron, if you'll recall, is a flat shaded universe. The textures, such as they are, are dead simple, and should compress down to nothing.
Yet, despite this, the download was 200 megs. It should have been no more than half that.
There has to be more efficient ways to handle this stuff.
I've written BeOS drivers for earlier versions of the FOCUS video encoder (beats Chrontel all to hell). The reference code FOCUS provided for porting was written for Linux so, unless it's a really recent chip, I know that at least some FOCUS chips have Linux support.
By freezing NVidia out of the DirectX-9 design talks, and working actively with ATI to optimize DX9 and the Radeon products toward each other. They also deliberately cobbled up DX9 standards to be incompatible with what NVidia was known to have on the drawing board. The most obvious example is DX9's use of 24-bit floats. There was no reason to define a wonky 3-byte quantity, except to be incompatible with NVidia's 16- and 32-bit floats. There are several other examples; just ask anyone in the games industry.
...lets face it Its the Dr's assistant that we all care about. She must be hot and able to screem [sic].
No.
After the easily-panicked Tegan, the whiny Peri, and the impossibly stupid and useless Mel, Ace/Dorothy was a welcome breath of fresh air.
Tegan at least had the benefit of reasonable stories, so the peril in which she found herself was at least plausible, but her voice grated after a while. Peri, portrayed as a spoiled American, would just sit and whine most of the time. And do not get me started on Mel, a strawberry blonde candy-striper clumsily written into the show who would stand motionless four feet from the Imminent Peril and scream at it. Granted, she could shatter transparent aluminium panels at 400 paces, but this super-power was never used to great effect by the writers.
Contrast with Ace. This woman did not take shit from anyone, and would blow you to smithereens as soon as look at you. ("Last one out's a gooey mess.") No idle simpering hostage, she. She was intelligent, resourceful and, while a bit chaotic, could always be relied upon to cause as much trouble for the bad guys as possible.
The assistant needs to be an assistant, not a tool for cheap plot devices.
Come off your high horse, software should have some level of liability and control, just like everything else that is every bit, and then some, complex as software development.
I rather like it up here on my horse, thank-you-very-much:-):-), but if you read what I wrote, I did not say that software should be exempt from product liability. I merely stated that the threshhold of culpability should be very high.
Part of the problem with software engineering as contrasted with "hard engineering" is that, when something fails, there's no wreckage to examine. If your bridge falls down, you can examine the debris for clues as to the nature of the failure (too much stress on a particular member, sheared-off rivet, sub-standard steel, sub-standard concrete, that truck was just too damn heavy, etc.). Moreover, this analysis can give you an idea of the bridge's history (how it was treated, which parts are more worn than others, did they rust-proof it on a regular basis, how much load it bore every day), which can give you further insight into the failure. Also, when you design and build a bridge, the finished product is typically delivered into the hands of a group of competent, educated people who understand bridge use and maintenance.
Software, on the other hand, leaves no debris. There is no aftermath to examine to determine what went wrong; you only have the user's word that, "It broke." (Hence the software engineer's refrain, "Try it again and see if it does the same thing." Determining repeatability is one of the few diagnostic tools we have.) Yes, UNIX systems will often deliver a core dump, but that doesn't give you a history of activity leading up to the failure, only a single snapshot in time, and probably not the moment in time where the real failure occurred. It also won't tell you if some other process went apesh*t and fandangoed on your core image (as is often the case in small/embedded systems). And if the RAM or CPU or disk in the machine is a cheap, flaky piece of doo-doo, well then...
Software engineering is still very much in its infancy, and our digital structures are being subjected to new and unanticipated uses and stresses every day. That's why I believe, for the time being, software product liability should not apply unless the vendor has a long, consistent history of being a complete chowderhead.
Though I am adamantly opposed to shrinkwrap "licenses," the one thing they do that I happen to agree with is the disclaimer of liability.
Writing solid software is hard. Writing solid software to run on cheap, unreliable hardware is even harder. Though we ridicule software vendors, crashing software is a fact of life. One day, new technologies or engineering practices may appear to make writing reliable software easier, or to allow the user to "reverse" the machine back to the last known good state so they can at least save their work. But for now, software is flaky and, undesireable though it may be, users need to plan appropriately.
That said, however, I believe there should be an exemption to the liability shield. Off the top of my head, the following factors should be considered to determine if liability should apply:
The scale of the failure (millions of compromised machines versus one guy's pr0n collection);
The vendor's demonstrated history of design/product flaws at first release;
The vendor's demonstrated history of correcting design/product flaws after release.
The scale of each factor would be weighed to determine whether the software vendor should suffer liability. This standard should be set fairly high. If a company is consistently pro-active in correcting bugs, releasing patches, and informing users; or the failures are comparatively minor; or their products exhibit failures on a comparatively rare basis -- in other words, if they are clearly a good, conscientious citizen of the computing community -- then the vendor should escape liability. OTOH, if a company can be shown to persistently use flawed methodologies and designs, and they regularly ignore bug reports until the excrement hits the rotary impeller, and the bug can cause widespread havoc, then the vendor should be exposed to liability.
Needless to say, Microsoft's 25-year history of releasing junk and not giving a $#!+ about it should be a reasonable foundation for a liability suit.
The downside to milestone-based payments is who decides when the work meets the requirements. If you don't have a detailed contract in place, the client can ding you for an almost endless series of little changes, claiming, "Well, we always expected it would do this."
Avoiding this means coming up with a very detailed requirements specification as well as test suite to prove the software meets the requirements. This effectively triples (or worse) the work you need to do (the work, plus negotiating and writing requirements docs, plus writing verification plans and tools).
Go for the hours. Depending on where you live, and how much other work you have, I wouldn't settle for less than $90-100/hour. If they balk, it's fairly easy to do some back-of-the-napkin calculations showing how much more it would cost them to have it done in-house.
...could [my] company turn around and sue for extortion/other illegality, since it has been proven in court that SCO has no legal basis to enforce/collect licensing fees?
Depending on how the license you buy from SCO is phrased, probably not.
If you buy a license from SCO, you are, in effect, placing a $700.00 bet on a roulette wheel that:
SCO will win its litigation against IBM (unlikely in the extreme), and,
The Court will grant SCO rights of action against an unbounded number of Linux users who cannot even be demonstrated that they, "should have known," Linux was tainted (impossible), and,
SCO will remain in buisiness long enough to come after you (highly improbable).
You might be able to sue them for fraudulently misrepresenting what they had to sell you. But since the license contract is the final description of what they're selling you, such a suit probably won't succeed.
After this remarkably long walk on a short legal pier, having received no useful guidance whatever from either party, the Court has endeavored, primarily based upon its affection for both counsel, but also out of its own sense of morbid curiosity, to resolve what it perceived to be the legal issue presented. Despite the waste of perfectly good crayon seen in both parties' briefing (and the inexplicable odor of wet dog emanating from such) the Court believes it has satisfactorily resolved this matter. Defendant's Motion for Summary Judgment is GRANTED.
Internet flamers, take heed: This is the standard to which you should aspire. Would that all cutting discourse on the net were posessed of such wit.
A likely explanation is that, since Micros~1 thinks the world revolves around them, they filed the briefs before midnight in Redmond. Wisconsin is two hours ahead.
Slashdot Mirror
This guy is not building a gaming platform. He's building a cable decoder.
Cable companies would like nothing more than to rent you immersive, persistent entertainment. ("Sell? That's so last millennium.") Problem: Cable boxes today are pitifully stupid due to the drive to keep costs low; they have no local storage. Also, they've learned the hard way, both through their spastic "Interactive TV" initiatives and their broadband internet offerings, that there's no way they can serve interactive games without intolerable download waits from the head end.
What they want is a PC that the subscriber can't modify in any way. It looks like the Phantom guys propose to build this.
Or, they could just be a bunch of flakes out to put over an obvious hoax on the industry. (Please support our "phantom" console, ha ha...)
Schwab
"Mr. Simpson, a word if you please."
"What's up, Principal Skinner?"
"Mr, Simpson, as you may recall during my school-wide address on Tuesday and Friday, all students were strongly encouraged to attend the school's homecoming football game."
"And?"
"And, there is no evidence of your presence in our RFID tracking records."
"I TiVo'ed it off public access cable."
"As I outlined in my address, that was not an acceptable form of team support."
"What's the big deal? It's just a crummy football game."
"Mr. Simpson, the value of a proper display of school spirit cannot be overemphasized. Failure to exhibit such spirit can have serious repercussions."
"You mean like what happened with Ralph Wiggum and the Christmas lights?"
"Precisely so, Mr. Simpson."
*shudders*
___________________
Schwab
That's why Mike Jittlov, creator of one the Best Damn Movies Ever Made, wrote his own birthday jingle and expressly entered it into the public domain.
Schwab
Wonderful. And only one document to lose or have stolen to deprive you of the right to drive, right to earn wages, right to be in the country, and right to travel. And probably also loss of your right to access to your money.
Oh, and proving who you are to get a replacement ID card becomes next to impossible, since all forms of corroborative identifaction have been supplanted by the One True ID.
Whether the government does it or private industry, it's a bad idea.
Schwab
Sony today announced it's latest line of personal entertainment products that, miraculously, don't need batteries, ever. Say hello to the new Sony NukeMan.
WARNING: RADIOLOGICAL HAZARD. DO NOT OPEN; NO USER-SERVICEABLE PARTS INSIDE. IF DEVICE BECOMES OVERLY WARM, IMMERSE IMMEDIATELY IN HEAVY WATER AND CALL THE U.S. ENVIRONMENTAL PROTECTION AGENCY'S RADIOLOGICAL EMERGENCY RESPONSE TEAM. DO NOT USE WHILE PREGNANT OR NURSING AN INFANT. DOES NOT CONFER SUPER-POWERS UPON USER. KEEP AWAY FROM EASILY-MUTATED ARACHNIDS.
Available in red, purple, pink, sky blue, and glow-in-the-dark green.
Schwab
Yes, but you must concede that this level of affordability is comparatively recent. As little as two years ago, you were paying more than that for 18G drives. And you must further concede that, for the same number of dollars, you'll get an IDE drive that's three times larger. And believe me, if you're at all a gamer, you can fill up 36G with remarkable speed.
Schwab
Fellow SCSI Bigot
P.S: Where are you finding PCI-X SCSI-320 controllers for under $200? Obviously these aren't Adaptecs...
After further thought, it seems I need to repudiate my own post:
The fact that UNIX is still here doesn't necessarily prove anything about the technical merits (or not) of UNIX.
I've been a UNIX user for two decades, and I enjoy it. However, I, too, have used "better" systems. A quick Google for 'ewhac' will reveal many, many posts by a past version of me extolling the virtues of the Amiga with great fervor. Amiga's basically dead now, through no fault of its technology or the imagination of its developers.
Despite the fact that I'm constantly amazed at the new hoops UNIX jumps through (embedded on PDAs?!!?), I'm still of the opinion that UNIX is big, heavy, and slow. UNIX, IMHO, would be a laughable choice for a gaming console (but so also would Windows-NT, and it seems I'm wrong about that, too). However, for a stable development and general purpose computing environment, I find UNIX a comfortable environment.
The point I was trying to make, perhaps with more bombast than was strictly necessary, is that, while UNIX does have flaws, I don't regard The UNIX-Hater's Handbook as an authoratative reference on the subject. The work discredits itself in my eyes by reading too much like a USENET flame.
Schwab
And repudiated by people equally if not more highly accredited. Or did you skip over the Anti-Foreword entirely?
I confess, I have not read The UNIX-Hater's Handbook cover to cover. I found a copy laying around, picked it up and read two or three pages at random. The pages I read were discrediting the curses(3) API for the fact that curses was a link library, not a shared library, and couldn't be transparently upgraded, thereby allowing apps to support new terminal types as support became available. This was presented as an indicative UNIX shortcoming. However, it relies heavily on the reader's lack of knowledge of UNIX history; curses was first developed before UNIX had shared libraries at all. Obviously, a shared library would have been superior, but they did not at that time exist. Should curses then have never been written, because link libraries, "suck?" Once UNIX got them, curses quickly became a shared library. "Problem" solved.
I made the presumption, perhaps inaccurately, that the rest of the book was like this -- a series of disingenuous arguments easily punctured by anyone with a reasonable historical and technical background. If so, the book merits no more attention than your typical USENET flamewar.
But the lethal stake through the heart of The UNIX-Hater's Handbook's underlying thesis -- namely, that UNIX sucks -- is the unarguable fact that UNIX is still here. The history of forces that have tried to kill UNIX in favor of something "better" are, in large part, studies of unsurpassing hubris. Microsoft -- the largest software company on the planet, with the "most talented" engineers on the planet (mostly by fiat, it would seem) -- has devoted major efforts to kill UNIX, first with OS/2, and then with Windows-NT derivatives. They have failed . Indeed, UNIX -- through Linux and BSD variants -- has only gotten stronger.
To cite The UNIX-Hater's Handbook as some sort of reference on bad software design shows little more than an appeal to a demonstrably false authority. UNIX is still here, and there is no indication it's going anywhere soon. The humble student will discover this is not accidental. There's a reason for this.
Schwab
Oh, how very droll.
Your first paragraph invokes a book written in no small part by Microsoft apologists. Your second describes sins committed largely by... Microsoft.
We remain unimpressed.
Schwab
Cool.
Is there a way to install and run it without having to install the rest of his daemon management stuff? I like to disrupt as few things as possible when making changes to my gateway.
Schwab
Haven't you been paying attention? AT&T has been farming out their customer service call centers to India.
Schwab
I attended the Vintage Computer Fair and found myself wondering aloud: Why can't software development be as simple as it was back when these machines were state of the art?
To get a program running on a C-64, you simply typed in:
10 PRINT "HELLO, WORLD!"
20 GOTO 10
RUN
And that was it! Real programming, available instantly.
Now, to write a program that employs Best Practices, you need to write code that:
And that doesn't include the whole compile-test-debug cycle. I mean, gah!. Programming is supposed to be simple. Just creating the skeleton framework for a simple app can take most of an afternoon, by which time the simple idea you just wanted to try out has lost its charm. Widget toolkits can shield you from only so much -- and they typically insulate you from some things you eventually find you don't want to be insulated from.
Computers have gotten a whole heck of a lot more powerful, but the number of details a programmer needs to keep track of has gone up by at least an order of magnitude.
Schwab
I did some extensive work in stereoscopy in the late 1980's, so I know a little bit about this. Basically what Sharp is using is a lenticular grille.
The key to stereoscopy is to feed different images to each eye. The brain interprets the parallax difference as depth. To see this sort of thing for yourself, close one eye, and hold two pencils vertically so that they line up one behind the other. Now switch eyes. The pencils appear to have "moved," and no longer appear lined up. This is because your other eye is in a different location, and sees from a different point of view ("duh"). This parallax separation in the left/right images is what triggers depth perception in the brain.
Okay, great, how do you get this on a computer display without funky glasses? Well, to use the pencils you already have, imagine that the farther pencil is the actual LCD pixel element, and the nearer pencil is a black band on a piece of glass/plastic in front of the pixel. One of your eyes cannot see the farther pencil, but the other one can. You have achieved a form of image separation without glasses.
Now, repeat across the entire horizontal display. Your left eye, being shifted slightly to the left, will see all the even-numbered pixel columns; and your right eye, being located slightly to the right, will see all the odd-numbered pixel columns. Result: Sufficient image separation to display and perceive steroscopy.
Problem: The optimum viewing location is fixed. You can be no closer or farther away than the prescribed location, or the images will bleed together or invert at the edges. Also, if your eyes are not centered, the lenticular grille will be effectively shifted relative to the pixel columns, and you'll experience stereo inversion (left and right images swapped; always good for a headache).
If you want to experiment with this stuff at home, and if you have access to a laser printer that will print on transparencies, print up for yourself a transparency with evenly spaced vertical lines, each one pixel in width -- one pixel width black, one pixel width clear, alternating. Lay this over your laptop screen and compose an image with alternating imagery in the odd/even pixel columns. Fun for the whole family!
Schwab
I just checked the filesize on this mod: 277 mebibytes. WTF?? I have a fairly fat pipe going to my house, but since when did it become a good idea to create demos and/or mods regularly exceeding 100 megs?
I recently downloaded the demo for Tron 2.0, weighing in at about 200 megs. Now, I might almost think this reasonable if it weren't for a few crucial facts:
Yet, despite this, the download was 200 megs. It should have been no more than half that.
There has to be more efficient ways to handle this stuff.
Schwab
I've written BeOS drivers for earlier versions of the FOCUS video encoder (beats Chrontel all to hell). The reference code FOCUS provided for porting was written for Linux so, unless it's a really recent chip, I know that at least some FOCUS chips have Linux support.
Schwab
By freezing NVidia out of the DirectX-9 design talks, and working actively with ATI to optimize DX9 and the Radeon products toward each other. They also deliberately cobbled up DX9 standards to be incompatible with what NVidia was known to have on the drawing board. The most obvious example is DX9's use of 24-bit floats. There was no reason to define a wonky 3-byte quantity, except to be incompatible with NVidia's 16- and 32-bit floats. There are several other examples; just ask anyone in the games industry.
Schwab
Step forward a couple of years, and it's remotely possible I'd say Yes. (1985 was the year the Amiga was released.)
Schwab
Don't worry, Microsoft will punish Eolas for uttering those words, just as they punished NVidia for those same words.
Schwab
No.
After the easily-panicked Tegan, the whiny Peri, and the impossibly stupid and useless Mel, Ace/Dorothy was a welcome breath of fresh air.
Tegan at least had the benefit of reasonable stories, so the peril in which she found herself was at least plausible, but her voice grated after a while. Peri, portrayed as a spoiled American, would just sit and whine most of the time. And do not get me started on Mel, a strawberry blonde candy-striper clumsily written into the show who would stand motionless four feet from the Imminent Peril and scream at it. Granted, she could shatter transparent aluminium panels at 400 paces, but this super-power was never used to great effect by the writers.
Contrast with Ace. This woman did not take shit from anyone, and would blow you to smithereens as soon as look at you. ("Last one out's a gooey mess.") No idle simpering hostage, she. She was intelligent, resourceful and, while a bit chaotic, could always be relied upon to cause as much trouble for the bad guys as possible.
The assistant needs to be an assistant, not a tool for cheap plot devices.
Schwab
I rather like it up here on my horse, thank-you-very-much :-) :-), but if you read what I wrote, I did not say that software should be exempt from product liability. I merely stated that the threshhold of culpability should be very high.
Part of the problem with software engineering as contrasted with "hard engineering" is that, when something fails, there's no wreckage to examine. If your bridge falls down, you can examine the debris for clues as to the nature of the failure (too much stress on a particular member, sheared-off rivet, sub-standard steel, sub-standard concrete, that truck was just too damn heavy, etc.). Moreover, this analysis can give you an idea of the bridge's history (how it was treated, which parts are more worn than others, did they rust-proof it on a regular basis, how much load it bore every day), which can give you further insight into the failure. Also, when you design and build a bridge, the finished product is typically delivered into the hands of a group of competent, educated people who understand bridge use and maintenance.
Software, on the other hand, leaves no debris. There is no aftermath to examine to determine what went wrong; you only have the user's word that, "It broke." (Hence the software engineer's refrain, "Try it again and see if it does the same thing." Determining repeatability is one of the few diagnostic tools we have.) Yes, UNIX systems will often deliver a core dump, but that doesn't give you a history of activity leading up to the failure, only a single snapshot in time, and probably not the moment in time where the real failure occurred. It also won't tell you if some other process went apesh*t and fandangoed on your core image (as is often the case in small/embedded systems). And if the RAM or CPU or disk in the machine is a cheap, flaky piece of doo-doo, well then...
Software engineering is still very much in its infancy, and our digital structures are being subjected to new and unanticipated uses and stresses every day. That's why I believe, for the time being, software product liability should not apply unless the vendor has a long, consistent history of being a complete chowderhead.
Schwab
Though I am adamantly opposed to shrinkwrap "licenses," the one thing they do that I happen to agree with is the disclaimer of liability.
Writing solid software is hard. Writing solid software to run on cheap, unreliable hardware is even harder. Though we ridicule software vendors, crashing software is a fact of life. One day, new technologies or engineering practices may appear to make writing reliable software easier, or to allow the user to "reverse" the machine back to the last known good state so they can at least save their work. But for now, software is flaky and, undesireable though it may be, users need to plan appropriately.
That said, however, I believe there should be an exemption to the liability shield. Off the top of my head, the following factors should be considered to determine if liability should apply:
The scale of each factor would be weighed to determine whether the software vendor should suffer liability. This standard should be set fairly high. If a company is consistently pro-active in correcting bugs, releasing patches, and informing users; or the failures are comparatively minor; or their products exhibit failures on a comparatively rare basis -- in other words, if they are clearly a good, conscientious citizen of the computing community -- then the vendor should escape liability. OTOH, if a company can be shown to persistently use flawed methodologies and designs, and they regularly ignore bug reports until the excrement hits the rotary impeller, and the bug can cause widespread havoc, then the vendor should be exposed to liability.
Needless to say, Microsoft's 25-year history of releasing junk and not giving a $#!+ about it should be a reasonable foundation for a liability suit.
Schwab
The downside to milestone-based payments is who decides when the work meets the requirements. If you don't have a detailed contract in place, the client can ding you for an almost endless series of little changes, claiming, "Well, we always expected it would do this."
Avoiding this means coming up with a very detailed requirements specification as well as test suite to prove the software meets the requirements. This effectively triples (or worse) the work you need to do (the work, plus negotiating and writing requirements docs, plus writing verification plans and tools).
Go for the hours. Depending on where you live, and how much other work you have, I wouldn't settle for less than $90-100/hour. If they balk, it's fairly easy to do some back-of-the-napkin calculations showing how much more it would cost them to have it done in-house.
Schwab
Depending on how the license you buy from SCO is phrased, probably not.
If you buy a license from SCO, you are, in effect, placing a $700.00 bet on a roulette wheel that:
You might be able to sue them for fraudulently misrepresenting what they had to sell you. But since the license contract is the final description of what they're selling you, such a suit probably won't succeed.
As always, talk to a real lawyer first.
Schwab
An excerpt from the parent's link:
Internet flamers, take heed: This is the standard to which you should aspire. Would that all cutting discourse on the net were posessed of such wit.
Schwab
A likely explanation is that, since Micros~1 thinks the world revolves around them, they filed the briefs before midnight in Redmond. Wisconsin is two hours ahead.
Schwab