You have never had a VCR with S-Video, but your VCR *has* had any one of the Component, DVI, HDMI, VGA, iLink, Ethernet, or wireless recording capability?? Anyway, S-Video was *allowed*, but plain old RF and Composite connectors are *mandated* to be part of the device. 100% guarantee any VCR you may have owned could record that.
If the spec required Macrovision added to the output, yes, but they didn't. No mention of doing anything with any sort of broadcast, etc.
Short and simple, these devices will explicitly allow Broadcast DTV to be hooked up to old fashioned VCRs as it stands. Unless the broadcast flag/some other draconian thing makes it by then (which is useless with already widely available tuner cards that don't care), this does nothing but ensure current broadcast availibility is maintained for both viewing and recording.
Sell the box at $300 dollars that is. It basically requires a slightly souped up DVD player sans optical drive, with an ATSC tuner. Today a consumer can have an ATSC tuner for less than 100 bucks to go into a computer. A DVD with the capabilities of decoding such a stream and downsampling it NTSC for a traditional set probably could be implemented at the 50-60 dollar price point. So as a commercial product in 2009, I would be very surprised to see no option under $100 dollars.
Ok, with the exception of the broadcast flag which has been struck down and not successfully resurrected, there is nothing of noteworthy DRM interest with respect to broadcast digital TV in how it compares to broadcast analog TV. The only thing people with antennas get different in broadcast TV is a signal that is perfect or *obviously* distorted. Depending on the quality of the set, the signal will most likely look better even than best-case analog signal.
I use rabbit ears (well, hoop antenna) with my Mythbox and ATSC tuner card just freaking fine and record to my hearts content (it's technically easier/cheaper to implement a perfect ATSC capture card, than a decent analog capture card, a decent analog card needs some sort of on-the-fly encoding, ATSC card just need dump the MPEG2 stream out. I don't have any problem recording TV at all.
Broadcast DTV is not DRM-encumbered at all. Cable companies enjoy a bit more DRM that is harder to break than their analog channel scrambling, but that is a moot point for ending analog broadcast TV and helping people to have the new standard accessible.
The era he speaks of, the NT4, 9x, 2k days, there were a fair number of mismatches, primarily in terms of drastically different driver models and levels of support for DirectX. Applications weren't that bad off for the most part, but the big picture was a lot more complex than most apps. Win2k, WinXP, Win2003 were not overly different, but NT to 2k, and now XP to Vista are moderately painful base platform changes..
The point was to say you can't excuse the lack of a docking station by saying 'oh, there is wireless, no one uses wires anymore'. I agree you can ignore it but don't pretend wires are obsolete in every context outside of power.
-Spyware/etc. point taken, but we have yet to see how well non-MS platforms hold up in the onslaught of common users faced with a large set of attackers. I've not seen any attempts at spyware/adware under linux yet, probably ditto for Mac. Some malware attempting to run without permission may be mitigated, but a lot of malware is invited in by users implicitly or explicitly installing it by their own free will, without realizing until later the consequences. -linux isn't actually that bad for common office use if the apps are sufficient in functionality. Start up a modern distro, and the manual install is easy and particularly brain-dead with automated network installs. Once in, it's very familiar, you click on nice menus/icons. To some extent, they mimick Windows more than OSX, so the migration may be easier to Gnome/KDE desktops than OSX, which embraces the filesystem structure with docked shortcuts more than a special-purpose menu as a means to find applications. On some level, I like the Apple approach, but most are familiar with the menu based approach. -Just because a fair number of webapps the author likes replaces some standalone apps or have grown to support firefox more, doesn't mean that Mac would do any better than PC or that this assessment is appropriate at a wide enough scale. -The intel chips are no more relevant to the discussion than ppc was a detractor. You are moving from one entirely different platform to another. PPC hypothetical cost difference (*if* true, only would matter if Apple were willing to pass on such savings to their consumers. Their price points really haven't budged. Well, there are exceptions. The Intel Mac Mini on release was $100 dollars more than the PPC based ancestor). In the past PPC was faster than x86 processors, but that performance delta meant little then, and now means absolutely nothing since they are just running equal with everyone else. The point on virtualization is somewhat interesting, but suspecting this comment made in the context of a desktop. Running Windows copies virtualized on desktops just means you have all the headaches of before, including license management, except you add OSX and application variants to the mesh. Not only that, but MS has taken interesting license stances on Windows running as a guest, so you may end up having to pay MS even *more* for the privilege of doing it. If they meant the PPC platform is not appropriate for virtualization in general, they obviously are not familiar with IBM's heritage of virtualization on Power servers (JS21 has a PPC970 dual core platform and includes hardware virtualization). Not with a Windows guest obviously, but it all depends on what he thought the promise of virtualization is. -Dunno about their integration to industry-wide directory schemes and whatnot, but it won't be any *better* than their competition at this point. -Creeping in from the home desktop is not that likely. Windows achieved it only through a combination of nearly complete home desktop market domination and a enterprise marketing/sales effort. Linux has done so more because it mimicked the featureset of expensive Unix solutions for both a reduced software cost and lower hardware investment that also happens to be a more vendor-neutral investment. The grass-roots component of the Linux growth is only because initially it had no explicit costs and the implicit costs were hidden through extra effort, frequently without extra billing, of the linux enthusiasts who wanted to make it work. More widespread adoption has required the corporate structures of the likes of RedHat and Novell, with partnerships of multiple hardware vendors. This is one *huge* area the Apple systems will probably *never* cope with. The whole point for a lot of companies going to the likes of Linux and Windows is the promise of vendor-neutrality. Dell x86 hardware or service pissed your company off, go to HP, and vice-versa. Don't have the budget for a Tier-One vendor for a peripheral project that doesn't demand tier-one support? Go
-Wireless means more maintenance in the context of Bluetooth, batteries to keep charged, etc. -Wireless networks do not scale well. Even at small scale performance isn't that great but at large scale the shared medium takes its toll beyond that. -Third point taken (network printers are more logical generally, centralized storage for data management also makes sense), but the mass storage on the other end runs into the above-mentioned performance aggravations.
A docking station shouldn't have to plug into the normal ports (you say a docking station would have to be on both sides of a mac). Generally laptops have a dedicated, frequently blind-mate, connection for docs that allow video, power, usb, and many more things.
Your last paragraph has more truth in it. Generally speaking the most painful thing anyone might deal with is external video. Power and USB connectors are so easy to manipulate that a docking station nowadays doesn't have to be the only way. Use HDMI for the video connector and everything is easy, except no VGA adapter possible for old projectors..
Yes, compared to a "real" gui, html forms don't have the same richness of user interaction possible. Guess what? For 90% of applications, that's a GOOD THING.
There are a few instances of basic GUI niceties that are often overlooked in webapps (because they are hard) that are trivially implemented in GUI. I'll give two prominent examples that are more than 20 years old (hardly "experimental") that are typically problematic for web development.
Drag and drop is a shining example of something 99.9% of webapps don't make any provision for that is *extremely* convenient (i.e. organize mail into folders, webmail interfaces frequently have a tree view on the left, and then for the mail move operation have a dropdown where you have to find your target even if it stares you in the face in the left pane, standalone mail apps have you drag and drop the message). This sort of data manipulation is not such a small part of most applications, and the fact that most web-based mail implementations don't do this (Zimbra does, to its credit) shows how simple webapps can be more painful than simple GUI (drag-and-drop for most all web dev architectures is still not easily acheived). Even when implemented internal to a webapp, forget entirely about using drag-and-drop as a means to relay a piece of information from one standalone application to another.
Another frequent thing that you *cannot* win in a webapp is the deal with context menus. Yes, some can and do override the context menu, but then it may or may not successfully suppress the browsers native context menu, if done right and always suppresses it, users will get pissed that their browsers menu is unusable. Either you implement your own context menu to break consistency with the rest of the browsing experience, or you have no context menu that may be crucial for easily using the application. The solution for webapp developers here is to clutter the screen with a lot of controls to eliminate the need for a context menu, but it is very cluttered, generally less well organized, and harder to tie to the context of what the user is doing.
CGI also enforces a fairly strict seperation between application guts and UI. Even in this day and age, many people still manage to mix these, to their sorrow.
Same is true of both standalone apps and webapps, developers can always shoot themselves in the foot regardless of the chosen technology. Neither web frameworks or GUIs in this day and age really foster the separation more than another. Most GUI frameworks if using any fancy IDE naturally establish separate files for presentation vs implementation.
Unlike GUI platform of your choice, CGI has not changed specification since, what, 1994? A script written then will still run today. The same can not be said of GTK or KDE or Mac apps, and I'm not so sure about Windows 3.1 to Windows Vista compatiblity either.
For a webapp, that is such a small part of the battle of a moderately useful application. The true test comes as to whether your outputted html will render as expected from 94 and if the javascript you wrote back then still runs exactly the way you say it do then. Add to that most functionality that has prevented the mass uptake of webapps has only in the past few years appeared in the browsers in a usable fashion (lots of Javascript and misc). Your script on the server side may run correctly (but likely not, in 94 you probably would have written a CGI application in C, and it may not run without a recompile on a modern platform, if some scripting language along the way, those too have changed). Your moving target is *not* the fundamental network protocol/communication format, the moving target is the server environment and the client web browsers. Firefox for a while has been fairly steady in terms of a good set of functionality (but so has GTK since GTK2), IE had a fairly hefty cleanup in IE7, whether future IE will change or not is yet to be seen. Declaring victory because CGI/HTTP/Ba
Your general description (a quick remote access thing for something) falls very much in the category of what a webapp would work well for, remote resource management for untrained personnel, ubiquitously available.
I will say your GUI app development time is exagerrated (GUI app, ok, not that big a deal, but an xml-rpc daemon to handle on/off? Just because xml-rpc is a buzzword doesn't mean you have to use it for every little thing, a daemon to this thing would be easy. Querying a database? Why in the world would you make it more difficult than it has to be (unless asterisk publishes it's info through a DB only) If your asterisk server is running a daemon specifically for this task, the amount of network debug should be minimal (you have three basic strings to get through, 'off' 'on' 'status, with a handful of response strings, add on for authentication almost nothing if using SSL and certificate authentication, a little more for anything else). If not over-engineered (which your high level design sounds to be), there isn't much for a client to screw up for this. Of course a single GUI app for 'on/off/status' is silly, and a single web page to do the same thing is less silly.
On distribution of your client app and the sheer sanity of having so many one-off applications from doing a single app for every little thing, the webapp has benefit (at least on Windows systems where you want to provide a visual queue for each app, hiding an app in/usr/bin isn't that big a deal on *nix systems). On managing shared resources (asterisk server status/shared files/etc) and having untrained people able to use the interface webapp is good (I have written one off daemons for experts that either simply interacted via telnet, or in more security minded scenarios used SSL and made them use openssl s_client to talk to the daemon, perhaps using certificates for authentication), or just had people ssh in and run the utility in the shell, but getting a receptionist to do all that is asking a bit much..) Of course, aside from ssh/otherwise remotely accessing the application, the webserver provides for authentication, which is good as implementing their own auth scheme can be a large exposure for a developer to screw up if they go to reinvent the wheel.
Are doomed to reinvent them, poorly, in a web browser.
The premise of the article is that a local application written to target a local server with web browser client is better, but then goes on to say essentially 'ok, here are all the pain in the ass things to overcome when trying to scale it down to a single user compared to typical web server environments'. In his article, he is trading one perceived pain in the ass set of things for another. The unstated stuff is you are requiring the unmentioned user to first have a webserver and CGI environment set up correctly before even beginning to run your app (since the aim is to be standalone on a box, the user's system is the server). He mentions some shortcuts you can take by assuming some network security things and no DB, but in the end the shortcuts are still more work than simple GUI apps for the equivalent task.
As to his fear of GUI toolkits, it's actually mostly silly. He sums it up by saying web browsers don't make you deal with 'resize events, window expose events, or menu events', but the truth is for a GUI application of the complexity he speaks of, GUI toolkits largely don't *make* you, they *let* you. If your application is as simple as what he prescribes, you can ignore that whole functionality of the toolkit. Sure you have to connect events to widgets of interest (i.e. buttons), but you have to do the exact same thing on webapps, but with different wording. If your application has some reason to start messing with the sort of stuff he fears dealing with and is implemented in a browser, a whole lot of pain is in store for you with obscure, platform specific javascript aplenty. Similarly, he mentions file opening/saving, and font management, but again, the toolkit usually has user-wide settings you can ignore the existence of just like a browser for font and style, and evoking the Toolkit standard filebrowser is usually exceedingly simple (along the lines of filename=Chooser() (not a specific language/toolkit)).
I have dealt with quite a few 'webapp-for-everything' people, generally they make web apps with an exceptionally clunky interface that responds poorly (I actually dislike Gmail's interface, but Zimbra was impressive, but still sluggish). If I find myself using it frequently and I can find out what it is frontending (usually a database for general apps, imap for mail, etc), then I write a quick GUI application or use a standard standalone app to do the same thing. I end up with a smoother interface that lets me be more productive, and often things run faster (webapp deployments are frequently the bottleneck, the backend could service far more than the webapp can push through for whatever reason). Whenever I do that and someone glances me interfacing with a system notoriously annoying in interface, they always want my application. Again, good Webapps can be on par with GUI apps, but for all the reasons the guy mentions, webapp developers mostly think implementing everything as simple forms is the way to go and that sucks for a lot of usage. GUI apps of course can be written piss-poor as well, but the typical GUI toolkit primitives are richer than simple HTML forms.
The only potential thing depending on how the app manages data and how it could be useful is the issue of scaling out/up. With a standalone GUI app, the barrier to running it remotely and having all your data in one place is higher than webapps (if running it remotely, must have X/RDP/VNC client installed on your random client which is less likely than a browser, if just having the data remote, still have to get the data accessible via some means and your client must have your software). This is a hard thing to define concretely, but the implementor should be able to make this determination fairly easily.
Disposable clients not thin clients are the answer for manageability. The cost savings of opting for a truly non-capable display-only device over a competent computer is essentially non-existent. Trying to pack all your processing overhead and memory into a centralized place will more than offset any perceived client-side savings. If you plan for it and can use the right tools, you should be able to go from an unconfigured blank system to a fully functional system with access to any arbitrary users data in under an hour. If you want to cut down workstation outages, you could do diskless with more RAM to have ramroot (if your OS allows), or switch to solid state storage. Fans of course will remain an item to service, but should be exceptionally painless to swap out that.
With the equipment available in this day and age, really thin computing where the desk local equipment does nothing but citrix/rdp/vnc/x forward from a server doing all the work doesn't usually make sense. As you say, doing all that stuff in a centralized way will be suboptimal and latencies annoying. You may be able to get the work done, but do not think for a minute your overall productivity and expense will go as you want them to.
The other end of the spectrum, everyone installing local applications and keeping most of their useful data offline on their disk all the time is also a nightmare in terms of maintenance and data reliability. You can address these, but at significant pain...
What I'd advocate is somewher in the middle. Essentially, disposable interchangeable workstations. Networking infrastructures can serve up filesystem access pretty well, and with the right set up, a client system's install can contain no data worth backing up. I.e. my home directory is nfs mounted on my workstation, and my mail and calendar stay on the imap/caldav servers. In my case, the workstation is linux and the company has an apt repo setup with all the important applications. The other day to test whether my setup allowed me to migrate freely, I got a different system, hooked it in, and within an hour I had my full setup on another system.
I don't have to endure the pain of high latency display nor do I put a huge memory/processing load at a place where the company has a hard time managing it, but at the same time my data does go right to a place they can easily manage and backup. The file access is slower a bit, but the company has a fairly beefy and robust setup that doesn't bother me too much.
Google makes a *lot* more sense for pay-as-you go with respect to productivity apps than MS' approach.
MS just wants a continual revenue stream for no additional effort. The problems they face as business is that their product very much fits with a purchase-once and use model. Once you have the software, i.e. when microsoft's development and delivery have succeded, MS is doing nothing by default. Sure, you get better support, but honestly how many times does the average person who *is* entitled ever bother to call for help? MS wants to have customers pay even if the customer is causing no work on MS's part, even if the upgrades they would provide mean nothing.
Google is very different. The most blatant thing is client independence, no need to maintain local software. But what really is interesting in terms of cost is you offload a lot of your data reliablity costs (backup) to the third party. By providing every remotely interesting thing from top to bottom, it's easy and an average person would never realize the implications of their data being backed up, how many disks a week are dying, etc etc. It's a logical extension of the server hosting model, and very much lends itself to a subscription model that all companies would like to follow in selling product.
My problem is some libraries I started getting into either didn't have python equivalents or the python equivalents were inconsistent. I'm trying to write software that will work with the greatest variety of distributions, and across the board the perl module variants are widely available and consistent. In python, some things aren't quite there, and some important modules have subtly different syntax between the distributions I need to support, all of which deviate from what you would download from upstream python world today. For 1 out of 5 lines of code in a particular python module I was writing, I was having to write the same thing three times in slightly different ways depending on the detecting version of the library. Didn't last long before I ditched that and ran to perl for this project despite my longstanding python experence.
I moved *to* perl from being an entirely python guy (started into perl and was 'ok' at it, but went to python for the same reasons a *lot* of people do). Python code is easy to write, but more importantly, *forces* writers to write code that is maintainable by others. Well, obfuscated python is possible, but with perl it's easy to casually fall into writing obfuscated code...
A lot of the perl culture doesn't help. If someone posts code to do something that is fairly reasonable, they may be mocked by another developer for not doing it in this hard to read/follow one liner they declare is 100% better because it fits on one line without a ; and uses no explicit variables...
I do have to acknowledge that perl doesn't *have* to look funky, most of the time you can make it fairly readable. Writing OO stuff is kinda weird as it feels like syntax that just happened to work really intended for cleanly packaging their version of include files. Variable referncing/dereferencing isn't all that different from C, but the function prototypes invite aggravation (values can be forced to be by reference without the caller realizing it, for example).
For my part, I try to write sane/legible perl. I try to be careful about indentions, I avoid almost entirely the likes of $_ and similarly invisible evocations of it which become hard to follow in all but the shortest loops, and when faced with anything but the simplest usage of it, I avoid using features of perl like map that tend to confuse people, and use more long-winded, but easier to follow conventions to get the job done.
But in the aggregate, it is unfortunate because the announcement of a new processor release suggests a hope of pushing the highest achievable performance up, and it is unfortunate that a new product does not fulfill such a hope. This is an industry-wide, vendor neutral way of expressing how it is unfortunate.
But, ultimately, it's probably because the writer is an AMD fanboy and really would like to claim some victory over Intel above and beyond what existing products could theoretically provide.
I will say of the orinoco/prism stuff, they are decent, only with hostap drivers, but for the life of me I cannot get it+wpa_supplicant to work on a LEAP network even though it works fine in a WPA2-PSK network...
The chipset to get in my experience is an ipw2100/ipw2200/etc... I've had those work effortlessly on numerous networks, WPA, LEAP, whatever.
I've had problems out of Atheros, but the sheer volume of those cards I think has caused support for them to improve lately, but I haven't tried in over a year...
Avoid broadcom... It's so damn weird you have to do so, their ethernet NICs have good first-party driver efforts, and yet you have to ndiswrapper to attempt their wireless parts... guess they accept they must do open-source drivers to be a serious linux market competitor, but don't think wireless linux is important... Also weird the linksys wireless boxes use broadcom chips with native, closed source broadcom drivers.
I haven't tried in years, but at last check, atmel chip driver sucked verily. By now that could've been fixed, but who cares with Intel chips...
There isn't even mention that the RIAA hired *these* same DJs.
Even if so, they do not say the projects for which this happened were RIAA sanctioned, explicitly or implicitly.
I think the leap of logic made is that RIAA sanctions this sort of activity, therefore it is hypocritical to punish it. The problem for them is that a DJ is, without their permission, and by extension without RIAA getting money for it, is duplicating and manipulating works that they have ownership rights of. Reproducing them and manipulating them for profit without RIAA getting a cut is fundamentally different from working with them and paying up. RIAA is within their legal rights and not overly deserving of the title hypocrite over this incident. Doesn't mean it is a smart move or that their other moves are not overstepping boundaries, but just that I can understand the difference between what they sanction vs. punish.
If the intended implication that 'maybe these DJs were authorized, but didn't get a contract to protect themselves', then it would be a boneheaded decision from the RIAA to do this to them. It would alienate a talent base that they obviously want to exploit (though the action probably alienated the talent base some, but not to the extent of turning down money for sanctioned work). Also, if they did commission the work, why wouldn't the RIAA have been distributing it for profit themselves? Ok, maybe it could be part of a move to do marketing for the original versions, but in any event if RIAA planned it all along, they ultimately screw themselves.
All that said, the particular case being discussed was handled poorly IMHO. First off the heavy-handedness of going in with SWAT over this made this a high-profile story (probably the whole point, a big 'don't fuck with the RIAA), but it turns into more RIAA looking like really bad guys, when they really could use some good publicity. This situation was at worst some people getting a little money from manipulating RIAA 'property' in ways they wouldn't have exactly done themselves and not really competing with RIAA, at best it was free marketing or, if the works were any good, an opportunity to discover talent to be exploited for money. You can bet most of these DJs are in it, in part, in hopes of a big RIAA company giving them a contract based on the works they put out. In order to prove yourself as a remixer, you have to remix something. In order to get sanctioned for rights to remix something, you have to remix in order to prove you are worth it. As long as the RIAA turned a blind eye to this, no catch22 existed, but if RIAA gets what they want and undiscovered talent stops doing it, the RIAA talent exploitation pool dries up.
Might be a cheaper way to kinda check it out. Most color blind people are trichromatic like everyone else, but very weak in red or green perception. Most are weak-green (deutan anomalous), but I happen to be weak-red (protan anomalous). If weak, you may be able to get a rough idea how an image would appear by amplifying your weak portion of the spectrum in images. It's the inverse of the process they use to show normal color vision people what color-blind people probably see where they drop the various colors down. Anyway, for example my television offers a feature to do just that and is labeled something like 'color correction for color vision impaired'. I find it handy in certain video game puzzles that require color discrimination.
That said, 99% of the time I leave the feature off. Ultimately, 'normal' is a relative term, and normal/realistic looking to me is matching what I've been seeing for the past few decades. Cranking up the red looks as weird to me as it does to everyone else, though my weird may be closer to their normal, that isn't how it works.
I think those born with a sensory deficiency/lack are luckier than those who lose it later. Though color deficiency is far from a big deal, especially to me, those around me upon finding out say 'oh, sorry to hear, that must suck'. When I have heavy congestion that diminishes my hearing for a while, I always feel a little bit of dread at the thought of persistant, merely incomplete hearing loss, and have a significant amount of relieve the moment that happens when things clear enough to hear well again.
In that case, no product had been shipped and no one got charged a price they did not agree to. It was bad because it was false advertising, but not as bad as 'you agree to pay x for product', then receiving product and being told 'we agreed and completed the transaction, but we renege on our deal and you will send you the product or, without your consent or any authorization, we will bill you retroactively for what we think the transaction *should* have been'. In the case of Best Buy, it was basically 'you will not receive the product unless you pay, and we will cancel the order if you do not, sorry for the mistake'. They did not charge anyone anything without *explicit* permission, while Amazon in this case is trying to charge based on 'if you agree to pay us, just don't say anything', which is clearly wrong.
This is not unreasonable to get angry over this, a company must be held accountable for their actions. They should never have cocked up, but as they automate this stuff more and more a bug can be costly, and a company has to plan on avoidance and recovery. In this case, the latest mechanism that should not have allowed this to pass was a order price check just before shipping. After that check failed, the company beyond any reasonable doubt should be held accountable for the cockup. If they catch it before the item is shipped and avoid the whole charge-without-express permission scenario, I can understand their position.
Since we are talking about Cell, yes, the leave one SPE disabled (to help yield) and Sony eats up one for their dedicated use, leaving game developers 6 instead of the full 8 SPEs. Even at this point, if you can reasonably express the algorithm in a way that is amenable to the BPEs, the Cell will wipe the floor with the equivalent processor. Getting to that point is not always possible for everything and often non-trivial for the things that will go there. It just so happens a lot of the hard problems that are of interest are theoretically amenable to the BPEs, so there is huge potential there.
Now, for algorithms that can not be or simply are not put in terms that make sense on the BPEs, the general purpose PPC core in the PS3 is wimpy and on those tasks will be easily beaten by a PC processor or the xbox360 processor(s). For a general purpose PC, a number of applications would be slow, but from the gaming perspective if the developer uses it effectively, it will do well.
The memory architecture is a tad faster on PS3, but dwarfed by the relatively pathetic memory amounts (256 for main and separate 256 for GPU), so game developers need be careful here.
Now the GPU is fairly boring in and of itself, and comparing that to PC variants of the GeForce chips today shows it to be relatively weak. As much noise as can be made about the Cell processor, a bulk of the 'oohs' and 'aahs' have to do with the GPU power..
Anyway, the whole point is that PC gaming is totally different and console gaming is about everyone having a highly consistent experience. Game developers have a much easier task with one specific hardware/software platform to target and don't have to worry about putting in the flexibility to accomodate a wide range of equipment. Add to that the fact that price/performance still favors consoles generally, and you know why except for specific genres (FPS and sims, which really need the interface paradigm of PCs to feel right) I don't really play PC games.
Where is it that a *complete* system featuring a GTS 8800 (currently cheapest on newegg is $390) and a C2D (cheapest on newegg $176 for an Allendale) can be had for under 500 bucks? I know newegg isn't absolutely the cheapest, but between those two components, a motheboard, memory, case, power supply, optical drive, hard drive, you *cannot* get under $500 with the particular items you call out.
Besides, as far as the purpose intended, the Cell processor and memory architecture of a PS3 is more sophisticated (speed-wise) than any core 2 duo system. The GPU lags behind the top end PC parts and the memory amount is low relative to what is realistic with PCs, but it isn't so easy to dismiss what the PS3 *does* bring to the market.
That said I have nearly zero interest in the PS3, no interesting games to me yet, and a fair number of series going to PS3 to me jumped the shark. Increasing the graphical complexity is nice, but not fundamentally more entertaining than PS2 games.
To try to shoehorn RE4 to line up some of the symbology to Silent Hill..
RE4 wasn't really the same sort of game as previous RE games, not really scary at all, just an action game for the most part. That said, RE has never struck me as being a particularly deep game series, for the most part simple resource scarcity and 'boo!' moments for relatively cheap suspense/horror. Extensive psychoanalysis of that series, particularly trying to pull in desire for a womb/sexual desire, comes off as a huge piece of bullshit to me.
Silent Hill's creators obviously very much buy into and intentionally incorporate every psychoanalysts dream smorgasbord of refrences/meaning. It ultimately makes it easy for psychoanalysts to roll through and point out the obvious things put in by the creators. Problem, for me at least, was the whole womb/room/umbilical cord thing just didn't strike me really. In fact, it kinda softened the impact of the whole thing because even as they tried to integrate it, it just seemed out-of-place, and not out of place in an eerie way, just in an almost funny 'reducing suspension of disbelief' sort of way. It was just so painfully obvious a psychological theory planted into the game that I've never took stock in. The fact that I didn't buy into it reinforces to me the decreased merit of 'everyone wants to be back in the womb' theories that pervade psychology. However, to me, Silent Hill *does* make good use of some deeper psychology to evoke deeper suspense and fear that is more persistant than anything in the Resident Evil series, so net Silent Hill's strategy of using more complex psychology works for them. To this end I was able to look past the parts that bugged me and enjoyed the overall game.
When I observe psychological archetypes that I do not believe have real meaning in a game, for me that's generally the point where I'm convinced (it fits so well, leaves my suspension of belief intact, and I can identify with the situation), or proves to myself that I'm not just being skeptical. Maybe it varies from person to person, but it seems most psychoanalysis is no where near as universal as the writers would have you believe.
Slashdot Mirror
You have never had a VCR with S-Video, but your VCR *has* had any one of the Component, DVI, HDMI, VGA, iLink, Ethernet, or wireless recording capability?? Anyway, S-Video was *allowed*, but plain old RF and Composite connectors are *mandated* to be part of the device. 100% guarantee any VCR you may have owned could record that.
If the spec required Macrovision added to the output, yes, but they didn't. No mention of doing anything with any sort of broadcast, etc.
Short and simple, these devices will explicitly allow Broadcast DTV to be hooked up to old fashioned VCRs as it stands. Unless the broadcast flag/some other draconian thing makes it by then (which is useless with already widely available tuner cards that don't care), this does nothing but ensure current broadcast availibility is maintained for both viewing and recording.
Sell the box at $300 dollars that is. It basically requires a slightly souped up DVD player sans optical drive, with an ATSC tuner. Today a consumer can have an ATSC tuner for less than 100 bucks to go into a computer. A DVD with the capabilities of decoding such a stream and downsampling it NTSC for a traditional set probably could be implemented at the 50-60 dollar price point. So as a commercial product in 2009, I would be very surprised to see no option under $100 dollars.
Ok, with the exception of the broadcast flag which has been struck down and not successfully resurrected, there is nothing of noteworthy DRM interest with respect to broadcast digital TV in how it compares to broadcast analog TV. The only thing people with antennas get different in broadcast TV is a signal that is perfect or *obviously* distorted. Depending on the quality of the set, the signal will most likely look better even than best-case analog signal.
I use rabbit ears (well, hoop antenna) with my Mythbox and ATSC tuner card just freaking fine and record to my hearts content (it's technically easier/cheaper to implement a perfect ATSC capture card, than a decent analog capture card, a decent analog card needs some sort of on-the-fly encoding, ATSC card just need dump the MPEG2 stream out. I don't have any problem recording TV at all.
Broadcast DTV is not DRM-encumbered at all. Cable companies enjoy a bit more DRM that is harder to break than their analog channel scrambling, but that is a moot point for ending analog broadcast TV and helping people to have the new standard accessible.
The era he speaks of, the NT4, 9x, 2k days, there were a fair number of mismatches, primarily in terms of drastically different driver models and levels of support for DirectX. Applications weren't that bad off for the most part, but the big picture was a lot more complex than most apps. Win2k, WinXP, Win2003 were not overly different, but NT to 2k, and now XP to Vista are moderately painful base platform changes..
The point was to say you can't excuse the lack of a docking station by saying 'oh, there is wireless, no one uses wires anymore'. I agree you can ignore it but don't pretend wires are obsolete in every context outside of power.
-Spyware/etc. point taken, but we have yet to see how well non-MS platforms hold up in the onslaught of common users faced with a large set of attackers. I've not seen any attempts at spyware/adware under linux yet, probably ditto for Mac. Some malware attempting to run without permission may be mitigated, but a lot of malware is invited in by users implicitly or explicitly installing it by their own free will, without realizing until later the consequences.
-linux isn't actually that bad for common office use if the apps are sufficient in functionality. Start up a modern distro, and the manual install is easy and particularly brain-dead with automated network installs. Once in, it's very familiar, you click on nice menus/icons. To some extent, they mimick Windows more than OSX, so the migration may be easier to Gnome/KDE desktops than OSX, which embraces the filesystem structure with docked shortcuts more than a special-purpose menu as a means to find applications. On some level, I like the Apple approach, but most are familiar with the menu based approach.
-Just because a fair number of webapps the author likes replaces some standalone apps or have grown to support firefox more, doesn't mean that Mac would do any better than PC or that this assessment is appropriate at a wide enough scale.
-The intel chips are no more relevant to the discussion than ppc was a detractor. You are moving from one entirely different platform to another. PPC hypothetical cost difference (*if* true, only would matter if Apple were willing to pass on such savings to their consumers. Their price points really haven't budged. Well, there are exceptions. The Intel Mac Mini on release was $100 dollars more than the PPC based ancestor). In the past PPC was faster than x86 processors, but that performance delta meant little then, and now means absolutely nothing since they are just running equal with everyone else. The point on virtualization is somewhat interesting, but suspecting this comment made in the context of a desktop. Running Windows copies virtualized on desktops just means you have all the headaches of before, including license management, except you add OSX and application variants to the mesh. Not only that, but MS has taken interesting license stances on Windows running as a guest, so you may end up having to pay MS even *more* for the privilege of doing it. If they meant the PPC platform is not appropriate for virtualization in general, they obviously are not familiar with IBM's heritage of virtualization on Power servers (JS21 has a PPC970 dual core platform and includes hardware virtualization). Not with a Windows guest obviously, but it all depends on what he thought the promise of virtualization is.
-Dunno about their integration to industry-wide directory schemes and whatnot, but it won't be any *better* than their competition at this point.
-Creeping in from the home desktop is not that likely. Windows achieved it only through a combination of nearly complete home desktop market domination and a enterprise marketing/sales effort. Linux has done so more because it mimicked the featureset of expensive Unix solutions for both a reduced software cost and lower hardware investment that also happens to be a more vendor-neutral investment. The grass-roots component of the Linux growth is only because initially it had no explicit costs and the implicit costs were hidden through extra effort, frequently without extra billing, of the linux enthusiasts who wanted to make it work. More widespread adoption has required the corporate structures of the likes of RedHat and Novell, with partnerships of multiple hardware vendors. This is one *huge* area the Apple systems will probably *never* cope with. The whole point for a lot of companies going to the likes of Linux and Windows is the promise of vendor-neutrality. Dell x86 hardware or service pissed your company off, go to HP, and vice-versa. Don't have the budget for a Tier-One vendor for a peripheral project that doesn't demand tier-one support? Go
-Wireless means more maintenance in the context of Bluetooth, batteries to keep charged, etc.
-Wireless networks do not scale well. Even at small scale performance isn't that great but at large scale the shared medium takes its toll beyond that.
-Third point taken (network printers are more logical generally, centralized storage for data management also makes sense), but the mass storage on the other end runs into the above-mentioned performance aggravations.
A docking station shouldn't have to plug into the normal ports (you say a docking station would have to be on both sides of a mac). Generally laptops have a dedicated, frequently blind-mate, connection for docs that allow video, power, usb, and many more things.
Your last paragraph has more truth in it. Generally speaking the most painful thing anyone might deal with is external video. Power and USB connectors are so easy to manipulate that a docking station nowadays doesn't have to be the only way. Use HDMI for the video connector and everything is easy, except no VGA adapter possible for old projectors..
Yes, compared to a "real" gui, html forms don't have the same richness of user interaction possible. Guess what? For 90% of applications, that's a GOOD THING.
There are a few instances of basic GUI niceties that are often overlooked in webapps (because they are hard) that are trivially implemented in GUI. I'll give two prominent examples that are more than 20 years old (hardly "experimental") that are typically problematic for web development.
Drag and drop is a shining example of something 99.9% of webapps don't make any provision for that is *extremely* convenient (i.e. organize mail into folders, webmail interfaces frequently have a tree view on the left, and then for the mail move operation have a dropdown where you have to find your target even if it stares you in the face in the left pane, standalone mail apps have you drag and drop the message). This sort of data manipulation is not such a small part of most applications, and the fact that most web-based mail implementations don't do this (Zimbra does, to its credit) shows how simple webapps can be more painful than simple GUI (drag-and-drop for most all web dev architectures is still not easily acheived). Even when implemented internal to a webapp, forget entirely about using drag-and-drop as a means to relay a piece of information from one standalone application to another.
Another frequent thing that you *cannot* win in a webapp is the deal with context menus. Yes, some can and do override the context menu, but then it may or may not successfully suppress the browsers native context menu, if done right and always suppresses it, users will get pissed that their browsers menu is unusable. Either you implement your own context menu to break consistency with the rest of the browsing experience, or you have no context menu that may be crucial for easily using the application. The solution for webapp developers here is to clutter the screen with a lot of controls to eliminate the need for a context menu, but it is very cluttered, generally less well organized, and harder to tie to the context of what the user is doing.
CGI also enforces a fairly strict seperation between application guts and UI. Even in this day and age, many people still manage to mix these, to their sorrow.
Same is true of both standalone apps and webapps, developers can always shoot themselves in the foot regardless of the chosen technology. Neither web frameworks or GUIs in this day and age really foster the separation more than another. Most GUI frameworks if using any fancy IDE naturally establish separate files for presentation vs implementation.
Unlike GUI platform of your choice, CGI has not changed specification since, what, 1994? A script written then will still run today. The same can not be said of GTK or KDE or Mac apps, and I'm not so sure about Windows 3.1 to Windows Vista compatiblity either.
For a webapp, that is such a small part of the battle of a moderately useful application. The true test comes as to whether your outputted html will render as expected from 94 and if the javascript you wrote back then still runs exactly the way you say it do then. Add to that most functionality that has prevented the mass uptake of webapps has only in the past few years appeared in the browsers in a usable fashion (lots of Javascript and misc). Your script on the server side may run correctly (but likely not, in 94 you probably would have written a CGI application in C, and it may not run without a recompile on a modern platform, if some scripting language along the way, those too have changed). Your moving target is *not* the fundamental network protocol/communication format, the moving target is the server environment and the client web browsers. Firefox for a while has been fairly steady in terms of a good set of functionality (but so has GTK since GTK2), IE had a fairly hefty cleanup in IE7, whether future IE will change or not is yet to be seen. Declaring victory because CGI/HTTP/Ba
Your general description (a quick remote access thing for something) falls very much in the category of what a webapp would work well for, remote resource management for untrained personnel, ubiquitously available.
/usr/bin isn't that big a deal on *nix systems). On managing shared resources (asterisk server status/shared files/etc) and having untrained people able to use the interface webapp is good (I have written one off daemons for experts that either simply interacted via telnet, or in more security minded scenarios used SSL and made them use openssl s_client to talk to the daemon, perhaps using certificates for authentication), or just had people ssh in and run the utility in the shell, but getting a receptionist to do all that is asking a bit much..) Of course, aside from ssh/otherwise remotely accessing the application, the webserver provides for authentication, which is good as implementing their own auth scheme can be a large exposure for a developer to screw up if they go to reinvent the wheel.
I will say your GUI app development time is exagerrated (GUI app, ok, not that big a deal, but an xml-rpc daemon to handle on/off? Just because xml-rpc is a buzzword doesn't mean you have to use it for every little thing, a daemon to this thing would be easy. Querying a database? Why in the world would you make it more difficult than it has to be (unless asterisk publishes it's info through a DB only) If your asterisk server is running a daemon specifically for this task, the amount of network debug should be minimal (you have three basic strings to get through, 'off' 'on' 'status, with a handful of response strings, add on for authentication almost nothing if using SSL and certificate authentication, a little more for anything else). If not over-engineered (which your high level design sounds to be), there isn't much for a client to screw up for this. Of course a single GUI app for 'on/off/status' is silly, and a single web page to do the same thing is less silly.
On distribution of your client app and the sheer sanity of having so many one-off applications from doing a single app for every little thing, the webapp has benefit (at least on Windows systems where you want to provide a visual queue for each app, hiding an app in
Are doomed to reinvent them, poorly, in a web browser.
The premise of the article is that a local application written to target a local server with web browser client is better, but then goes on to say essentially 'ok, here are all the pain in the ass things to overcome when trying to scale it down to a single user compared to typical web server environments'. In his article, he is trading one perceived pain in the ass set of things for another. The unstated stuff is you are requiring the unmentioned user to first have a webserver and CGI environment set up correctly before even beginning to run your app (since the aim is to be standalone on a box, the user's system is the server). He mentions some shortcuts you can take by assuming some network security things and no DB, but in the end the shortcuts are still more work than simple GUI apps for the equivalent task.
As to his fear of GUI toolkits, it's actually mostly silly. He sums it up by saying web browsers don't make you deal with 'resize events, window expose events, or menu events', but the truth is for a GUI application of the complexity he speaks of, GUI toolkits largely don't *make* you, they *let* you. If your application is as simple as what he prescribes, you can ignore that whole functionality of the toolkit. Sure you have to connect events to widgets of interest (i.e. buttons), but you have to do the exact same thing on webapps, but with different wording. If your application has some reason to start messing with the sort of stuff he fears dealing with and is implemented in a browser, a whole lot of pain is in store for you with obscure, platform specific javascript aplenty. Similarly, he mentions file opening/saving, and font management, but again, the toolkit usually has user-wide settings you can ignore the existence of just like a browser for font and style, and evoking the Toolkit standard filebrowser is usually exceedingly simple (along the lines of filename=Chooser() (not a specific language/toolkit)).
I have dealt with quite a few 'webapp-for-everything' people, generally they make web apps with an exceptionally clunky interface that responds poorly (I actually dislike Gmail's interface, but Zimbra was impressive, but still sluggish). If I find myself using it frequently and I can find out what it is frontending (usually a database for general apps, imap for mail, etc), then I write a quick GUI application or use a standard standalone app to do the same thing. I end up with a smoother interface that lets me be more productive, and often things run faster (webapp deployments are frequently the bottleneck, the backend could service far more than the webapp can push through for whatever reason). Whenever I do that and someone glances me interfacing with a system notoriously annoying in interface, they always want my application. Again, good Webapps can be on par with GUI apps, but for all the reasons the guy mentions, webapp developers mostly think implementing everything as simple forms is the way to go and that sucks for a lot of usage. GUI apps of course can be written piss-poor as well, but the typical GUI toolkit primitives are richer than simple HTML forms.
The only potential thing depending on how the app manages data and how it could be useful is the issue of scaling out/up. With a standalone GUI app, the barrier to running it remotely and having all your data in one place is higher than webapps (if running it remotely, must have X/RDP/VNC client installed on your random client which is less likely than a browser, if just having the data remote, still have to get the data accessible via some means and your client must have your software). This is a hard thing to define concretely, but the implementor should be able to make this determination fairly easily.
Disposable clients not thin clients are the answer for manageability. The cost savings of opting for a truly non-capable display-only device over a competent computer is essentially non-existent. Trying to pack all your processing overhead and memory into a centralized place will more than offset any perceived client-side savings. If you plan for it and can use the right tools, you should be able to go from an unconfigured blank system to a fully functional system with access to any arbitrary users data in under an hour. If you want to cut down workstation outages, you could do diskless with more RAM to have ramroot (if your OS allows), or switch to solid state storage. Fans of course will remain an item to service, but should be exceptionally painless to swap out that.
With the equipment available in this day and age, really thin computing where the desk local equipment does nothing but citrix/rdp/vnc/x forward from a server doing all the work doesn't usually make sense. As you say, doing all that stuff in a centralized way will be suboptimal and latencies annoying. You may be able to get the work done, but do not think for a minute your overall productivity and expense will go as you want them to.
The other end of the spectrum, everyone installing local applications and keeping most of their useful data offline on their disk all the time is also a nightmare in terms of maintenance and data reliability. You can address these, but at significant pain...
What I'd advocate is somewher in the middle. Essentially, disposable interchangeable workstations. Networking infrastructures can serve up filesystem access pretty well, and with the right set up, a client system's install can contain no data worth backing up. I.e. my home directory is nfs mounted on my workstation, and my mail and calendar stay on the imap/caldav servers. In my case, the workstation is linux and the company has an apt repo setup with all the important applications. The other day to test whether my setup allowed me to migrate freely, I got a different system, hooked it in, and within an hour I had my full setup on another system.
I don't have to endure the pain of high latency display nor do I put a huge memory/processing load at a place where the company has a hard time managing it, but at the same time my data does go right to a place they can easily manage and backup. The file access is slower a bit, but the company has a fairly beefy and robust setup that doesn't bother me too much.
Google makes a *lot* more sense for pay-as-you go with respect to productivity apps than MS' approach.
MS just wants a continual revenue stream for no additional effort. The problems they face as business is that their product very much fits with a purchase-once and use model. Once you have the software, i.e. when microsoft's development and delivery have succeded, MS is doing nothing by default. Sure, you get better support, but honestly how many times does the average person who *is* entitled ever bother to call for help? MS wants to have customers pay even if the customer is causing no work on MS's part, even if the upgrades they would provide mean nothing.
Google is very different. The most blatant thing is client independence, no need to maintain local software. But what really is interesting in terms of cost is you offload a lot of your data reliablity costs (backup) to the third party. By providing every remotely interesting thing from top to bottom, it's easy and an average person would never realize the implications of their data being backed up, how many disks a week are dying, etc etc. It's a logical extension of the server hosting model, and very much lends itself to a subscription model that all companies would like to follow in selling product.
My problem is some libraries I started getting into either didn't have python equivalents or the python equivalents were inconsistent. I'm trying to write software that will work with the greatest variety of distributions, and across the board the perl module variants are widely available and consistent. In python, some things aren't quite there, and some important modules have subtly different syntax between the distributions I need to support, all of which deviate from what you would download from upstream python world today. For 1 out of 5 lines of code in a particular python module I was writing, I was having to write the same thing three times in slightly different ways depending on the detecting version of the library. Didn't last long before I ditched that and ran to perl for this project despite my longstanding python experence.
I moved *to* perl from being an entirely python guy (started into perl and was 'ok' at it, but went to python for the same reasons a *lot* of people do). Python code is easy to write, but more importantly, *forces* writers to write code that is maintainable by others. Well, obfuscated python is possible, but with perl it's easy to casually fall into writing obfuscated code...
A lot of the perl culture doesn't help. If someone posts code to do something that is fairly reasonable, they may be mocked by another developer for not doing it in this hard to read/follow one liner they declare is 100% better because it fits on one line without a ; and uses no explicit variables...
I do have to acknowledge that perl doesn't *have* to look funky, most of the time you can make it fairly readable. Writing OO stuff is kinda weird as it feels like syntax that just happened to work really intended for cleanly packaging their version of include files. Variable referncing/dereferencing isn't all that different from C, but the function prototypes invite aggravation (values can be forced to be by reference without the caller realizing it, for example).
For my part, I try to write sane/legible perl. I try to be careful about indentions, I avoid almost entirely the likes of $_ and similarly invisible evocations of it which become hard to follow in all but the shortest loops, and when faced with anything but the simplest usage of it, I avoid using features of perl like map that tend to confuse people, and use more long-winded, but easier to follow conventions to get the job done.
AMD still does maintain a stronger memory architecture, stream numbers out of AMD platform systems are much higher than comparable intel.
Of course, this processor does nothing to widen that gap or anything..
It is unfortunate obviously for AMD.
But in the aggregate, it is unfortunate because the announcement of a new processor release suggests a hope of pushing the highest achievable performance up, and it is unfortunate that a new product does not fulfill such a hope. This is an industry-wide, vendor neutral way of expressing how it is unfortunate.
But, ultimately, it's probably because the writer is an AMD fanboy and really would like to claim some victory over Intel above and beyond what existing products could theoretically provide.
I will say of the orinoco/prism stuff, they are decent, only with hostap drivers, but for the life of me I cannot get it+wpa_supplicant to work on a LEAP network even though it works fine in a WPA2-PSK network...
The chipset to get in my experience is an ipw2100/ipw2200/etc... I've had those work effortlessly on numerous networks, WPA, LEAP, whatever.
I've had problems out of Atheros, but the sheer volume of those cards I think has caused support for them to improve lately, but I haven't tried in over a year...
Avoid broadcom... It's so damn weird you have to do so, their ethernet NICs have good first-party driver efforts, and yet you have to ndiswrapper to attempt their wireless parts... guess they accept they must do open-source drivers to be a serious linux market competitor, but don't think wireless linux is important... Also weird the linksys wireless boxes use broadcom chips with native, closed source broadcom drivers.
I haven't tried in years, but at last check, atmel chip driver sucked verily. By now that could've been fixed, but who cares with Intel chips...
There isn't even mention that the RIAA hired *these* same DJs.
Even if so, they do not say the projects for which this happened were RIAA sanctioned, explicitly or implicitly.
I think the leap of logic made is that RIAA sanctions this sort of activity, therefore it is hypocritical to punish it. The problem for them is that a DJ is, without their permission, and by extension without RIAA getting money for it, is duplicating and manipulating works that they have ownership rights of. Reproducing them and manipulating them for profit without RIAA getting a cut is fundamentally different from working with them and paying up. RIAA is within their legal rights and not overly deserving of the title hypocrite over this incident. Doesn't mean it is a smart move or that their other moves are not overstepping boundaries, but just that I can understand the difference between what they sanction vs. punish.
If the intended implication that 'maybe these DJs were authorized, but didn't get a contract to protect themselves', then it would be a boneheaded decision from the RIAA to do this to them. It would alienate a talent base that they obviously want to exploit (though the action probably alienated the talent base some, but not to the extent of turning down money for sanctioned work). Also, if they did commission the work, why wouldn't the RIAA have been distributing it for profit themselves? Ok, maybe it could be part of a move to do marketing for the original versions, but in any event if RIAA planned it all along, they ultimately screw themselves.
All that said, the particular case being discussed was handled poorly IMHO. First off the heavy-handedness of going in with SWAT over this made this a high-profile story (probably the whole point, a big 'don't fuck with the RIAA), but it turns into more RIAA looking like really bad guys, when they really could use some good publicity. This situation was at worst some people getting a little money from manipulating RIAA 'property' in ways they wouldn't have exactly done themselves and not really competing with RIAA, at best it was free marketing or, if the works were any good, an opportunity to discover talent to be exploited for money. You can bet most of these DJs are in it, in part, in hopes of a big RIAA company giving them a contract based on the works they put out. In order to prove yourself as a remixer, you have to remix something. In order to get sanctioned for rights to remix something, you have to remix in order to prove you are worth it. As long as the RIAA turned a blind eye to this, no catch22 existed, but if RIAA gets what they want and undiscovered talent stops doing it, the RIAA talent exploitation pool dries up.
Might be a cheaper way to kinda check it out. Most color blind people are trichromatic like everyone else, but very weak in red or green perception. Most are weak-green (deutan anomalous), but I happen to be weak-red (protan anomalous). If weak, you may be able to get a rough idea how an image would appear by amplifying your weak portion of the spectrum in images. It's the inverse of the process they use to show normal color vision people what color-blind people probably see where they drop the various colors down. Anyway, for example my television offers a feature to do just that and is labeled something like 'color correction for color vision impaired'. I find it handy in certain video game puzzles that require color discrimination.
That said, 99% of the time I leave the feature off. Ultimately, 'normal' is a relative term, and normal/realistic looking to me is matching what I've been seeing for the past few decades. Cranking up the red looks as weird to me as it does to everyone else, though my weird may be closer to their normal, that isn't how it works.
I think those born with a sensory deficiency/lack are luckier than those who lose it later. Though color deficiency is far from a big deal, especially to me, those around me upon finding out say 'oh, sorry to hear, that must suck'. When I have heavy congestion that diminishes my hearing for a while, I always feel a little bit of dread at the thought of persistant, merely incomplete hearing loss, and have a significant amount of relieve the moment that happens when things clear enough to hear well again.
In that case, no product had been shipped and no one got charged a price they did not agree to. It was bad because it was false advertising, but not as bad as 'you agree to pay x for product', then receiving product and being told 'we agreed and completed the transaction, but we renege on our deal and you will send you the product or, without your consent or any authorization, we will bill you retroactively for what we think the transaction *should* have been'. In the case of Best Buy, it was basically 'you will not receive the product unless you pay, and we will cancel the order if you do not, sorry for the mistake'. They did not charge anyone anything without *explicit* permission, while Amazon in this case is trying to charge based on 'if you agree to pay us, just don't say anything', which is clearly wrong.
This is not unreasonable to get angry over this, a company must be held accountable for their actions. They should never have cocked up, but as they automate this stuff more and more a bug can be costly, and a company has to plan on avoidance and recovery. In this case, the latest mechanism that should not have allowed this to pass was a order price check just before shipping. After that check failed, the company beyond any reasonable doubt should be held accountable for the cockup. If they catch it before the item is shipped and avoid the whole charge-without-express permission scenario, I can understand their position.
iptables -I FORWARD -s -j DROP
iptables -I INPUT -s -j DROP
Replace with favorite firewall appropriate commands.
MUCH quicker, cheaper, and probably more effective than trying to blow up the source.
Depends on the processor.
Since we are talking about Cell, yes, the leave one SPE disabled (to help yield) and Sony eats up one for their dedicated use, leaving game developers 6 instead of the full 8 SPEs. Even at this point, if you can reasonably express the algorithm in a way that is amenable to the BPEs, the Cell will wipe the floor with the equivalent processor. Getting to that point is not always possible for everything and often non-trivial for the things that will go there. It just so happens a lot of the hard problems that are of interest are theoretically amenable to the BPEs, so there is huge potential there.
Now, for algorithms that can not be or simply are not put in terms that make sense on the BPEs, the general purpose PPC core in the PS3 is wimpy and on those tasks will be easily beaten by a PC processor or the xbox360 processor(s). For a general purpose PC, a number of applications would be slow, but from the gaming perspective if the developer uses it effectively, it will do well.
The memory architecture is a tad faster on PS3, but dwarfed by the relatively pathetic memory amounts (256 for main and separate 256 for GPU), so game developers need be careful here.
Now the GPU is fairly boring in and of itself, and comparing that to PC variants of the GeForce chips today shows it to be relatively weak. As much noise as can be made about the Cell processor, a bulk of the 'oohs' and 'aahs' have to do with the GPU power..
Anyway, the whole point is that PC gaming is totally different and console gaming is about everyone having a highly consistent experience. Game developers have a much easier task with one specific hardware/software platform to target and don't have to worry about putting in the flexibility to accomodate a wide range of equipment. Add to that the fact that price/performance still favors consoles generally, and you know why except for specific genres (FPS and sims, which really need the interface paradigm of PCs to feel right) I don't really play PC games.
Where is it that a *complete* system featuring a GTS 8800 (currently cheapest on newegg is $390) and a C2D (cheapest on newegg $176 for an Allendale) can be had for under 500 bucks? I know newegg isn't absolutely the cheapest, but between those two components, a motheboard, memory, case, power supply, optical drive, hard drive, you *cannot* get under $500 with the particular items you call out.
Besides, as far as the purpose intended, the Cell processor and memory architecture of a PS3 is more sophisticated (speed-wise) than any core 2 duo system. The GPU lags behind the top end PC parts and the memory amount is low relative to what is realistic with PCs, but it isn't so easy to dismiss what the PS3 *does* bring to the market.
That said I have nearly zero interest in the PS3, no interesting games to me yet, and a fair number of series going to PS3 to me jumped the shark. Increasing the graphical complexity is nice, but not fundamentally more entertaining than PS2 games.
To try to shoehorn RE4 to line up some of the symbology to Silent Hill..
RE4 wasn't really the same sort of game as previous RE games, not really scary at all, just an action game for the most part. That said, RE has never struck me as being a particularly deep game series, for the most part simple resource scarcity and 'boo!' moments for relatively cheap suspense/horror. Extensive psychoanalysis of that series, particularly trying to pull in desire for a womb/sexual desire, comes off as a huge piece of bullshit to me.
Silent Hill's creators obviously very much buy into and intentionally incorporate every psychoanalysts dream smorgasbord of refrences/meaning. It ultimately makes it easy for psychoanalysts to roll through and point out the obvious things put in by the creators. Problem, for me at least, was the whole womb/room/umbilical cord thing just didn't strike me really. In fact, it kinda softened the impact of the whole thing because even as they tried to integrate it, it just seemed out-of-place, and not out of place in an eerie way, just in an almost funny 'reducing suspension of disbelief' sort of way. It was just so painfully obvious a psychological theory planted into the game that I've never took stock in. The fact that I didn't buy into it reinforces to me the decreased merit of 'everyone wants to be back in the womb' theories that pervade psychology. However, to me, Silent Hill *does* make good use of some deeper psychology to evoke deeper suspense and fear that is more persistant than anything in the Resident Evil series, so net Silent Hill's strategy of using more complex psychology works for them. To this end I was able to look past the parts that bugged me and enjoyed the overall game.
When I observe psychological archetypes that I do not believe have real meaning in a game, for me that's generally the point where I'm convinced (it fits so well, leaves my suspension of belief intact, and I can identify with the situation), or proves to myself that I'm not just being skeptical. Maybe it varies from person to person, but it seems most psychoanalysis is no where near as universal as the writers would have you believe.
In psychology, everything is either about sex, or your mother, but usually both at the same time...