I call BS on this whole article. It's exactly the kind of thing I hear (with minor variations) from anyone who's not into computer gaming, especially those too old to have started as kids.
"Am I the only one who expects a collapse of the gaming business soon? Does anyone else think that it is overdue? It has happened before,"
When, exactly? When was computer gaming ever as big as it is now, and when did it subsequently collapse? And even if it did, the fact that it's back and as big as it is now downgrades that from a "collapse" to a "temporary dip".
"and I can't see how people will keep shelling out $50 or so for a video game when the games have hardly changed since the invention of the first-person shooter."
So when did that ever matter? There are about five-ten genres of games, and there are already one or more examples which are considered pretty definitive, or were at the time (shooters = Half-Life 2, RTS = Dune/C&C/Total Annihilation, Point-and-Click Adventure = Sam&Max/Curse of Monkey Island, etc).
Having these definitive games around didn't stop people producing new (and better/more complex/more involving) ones, did it? The point is the differences between the games, not the similarities.
And ok, $50 is a lot for a game, and we'd all like it if it was cheaper. But you'll pay $15 for a DVD, and that lasts a tiny fraction of the time a good game does.
"I complain to my kids about this, and they insist that things have changed markedly. They show me examples, and all I see are tweaks and weirder, mostly stupid weapons."
Yeah. But what they're showing you is new gameplay dynamics, improved graphics, better immersion and a more engaging storyline, you inattentive and obdurate prat.
"There are four or five simple game categories and nothing really new or different."
Ignoring the conservative "genre" number... Yeah, and before Dune/C&C there would have been four game categories, until someone invented one. But you can't do that forever - at some point someone will have tried every game-style worth playing, and the only thing to do is to make them technically better, and more involving.
Let's face it - as Aristotle thought, practically every movie can be broken down into the basic "initial balance/disruption of balance/re-establishment of balance" structure. Does this mean that every movie is the same? So should the movie industry collapse? No, because what's important is not the details of how you interact with the film, but the story the film tells.
Likewise, computer gaming is moving away from frantic innovation in how you interact with the game, more towards cinematic, immersive stories. That's evolution, not death.
"When my kids show me a game, I usually say that it's nothing but the same old running-jumping-kicking-shooting with a new background."
Bingo - that's because you're old, out-of-touch and writing an article on something about which you know nothing. Show me a Bollywood movie and all I see is a lot of silly dancing-annoying music-cheesy-plot twists with new costumes, but I don't assume that the entire Bollywood movie industry is without artistic merit and destined to die on its arse. That's because I don't have my head jammed up my arse, and don't assume that "I don't understand" = "Contains no merit whatsoever".
"in almost all the big games, the so-called boss characters are all beginning to be pretty much the same: big, creepy monsters."
Apart from the ones which are big, creepy robots. Or large, tough fighters. Or large numbers of smaller weaker units working together, or...
Actually, John, they're just tougher challenges and moments of heightened tension, and it so happens that often equates to "bigger and creepier". But not always.
"If you want to see... how inane this is... rent... Starship Troopers... It's essentially a video game turned
But why is this? I was under the impression that this was the reason DirectX existed - to abstract the interface form the hardware, so developing for the PC was more like developing for a console.
These days, with the availability of high-level APIs, does this excuse really stack up? Or is it just a convenient games-industry euphamism for "Microsoft kept throwing money at us until we agreed"?
I agree - COM is interesting, but it's event-driven reactivity I'm really interested in. We've already got at least two different ways to instruct another app what to do (windowmessages and COM) - I want a third-party app to report back to me what it's doing/done so I can decide what to tell it next.
You're pretty close to what I originally envisaged with your last sentance, but I was thinking more along the lines of:
1) Set a CD burning in Nero (or whatever). 2) Hook the "I'm finished" event throught the gui - either the CD Burner gives you a list of exposed high-level events, or maybe Ctrl+Alt+Right-click on the progress bar to set it at the widget level. 3) Select the OnBurnFinished()/ProgressBar.OnChange() event (depending how it's exposed in 2) and add the body of the function:
Obviously this is a very rough idea, but it adds a huge level of usability to the system (far beyond just being able to effectively script apps in batch-mode), and I can't see any show-stopping problems that would prevent it from being practical...
Well, the idea would be that as much of the setup as possible would be offloaded onto the framework/IDE (Visual Studio, or whatever) - developers are inherently lazy (I know, I am one), and advanced usability like this just isn't considered enough of a priority (yet) to bother expending any effort on it. If it would work it'd have to be something that came essentially "for free" with the framework, unless we're going to see a revolution in the direction of semantic app development, like we've seen in web development (unlikely).
Obviously the programmer would still have to identify scenarios where you'd want app-specific stuff, but I can see many useful (and general) cases where it could be automated - how about having a scriptable "progress bar reached 100%" event? Although there are obvious issues still to resolve, this would essentially allow you to attach events to media players finishing tracks, CD burners finishing burns, etc, etc, etc, all from one small (automatic) change, at the widget level.
Scriptability on a per-application basis would do as a beginning, although obviously ideally every app would be scriptable. Mind you, this could be phased in gradually in a per-app basis, much as MFC or.NET apps were phased in. Having the platform handle most/all of the work also means that to upgrade your existing program all you'd have to do is recompile it. Ok, Win API stuff would be a re-writing nightmare, but this kind of scriptability as an extension to the MFC or.NET platforms? Should be fairly easy.
Backwards compatability shouldn't be a problem - new apps expose the new interface, and old apps don't. Just like COM/ActiveX/Automation/whatever. Of course, that makes old apps less useful/usable, but that only gently encourages people to update them...
Yeah, I use Nero, and love that bit of functionality. In fact, the original thought came from the frustration that every app didn't offer that kind of option, and wondering why there wasn't a more general way to specify advanced behaviours like "shutdown when finished"...;-)
A few years ago I actually hacked up a vaguely similar system from the "other side" - it allowed you to select a window with the mouse, grabbed a window handle to it and allowed you to write scripts to send windowmessages to that window. Once attached to a window the scripts could be fired however you wanted (I only got as far as writing a voice control front-end in the end).
What we're talking about here is competing the loop - having the app itself expose events (report status) back so it can trigger behaviour in other programs, rather than just executing windowmessages (following instructions) sent to it.
You know, the more I think about this, the more tempted I am to see if it's possible to go anywhere with this...
I'm well aware of COM (despite, I admit, not having written large numbers of COM apps), and yes, it does provide a good start. However, it's also several years old, and ActiveX (the closest thing we've had to an update) is in many ways (security?) a giant leap backward.
Granted, OLE/COM has many benefits (and does, for example, offer clipboard functionality second-to-none), but I wasn't really talking about accessing and manipulating the deep-internal data structures of a program. Windows (with COM) already has this pretty much down-pat (assuming the original coder thought to provide the opportunity), but this is only really of much use to "Windows Developers" and hardcore sysadmins.
I was talking more about quick, easy scripting of user-interface functionality - extending what we've got from "internal data structures" (as a lot of COM/ActiveX objects are concerned with) to things that actually matter to normal users
For example, I frequently set a CD burning (or music/movie playing, or download going), then go to bed/go out/do something else. Why can't I call up (in the UI) a simple list of all the events the program exposes, and attach a short script to an "I'm finished processing" one? This event could be fired by any app which had a "single large job" to do - burning a CD for CD burners, reaching the end of a movie/playlist for media players, transcoding a file in a DVD ripper/converter, etc.
I could tell winamp to shut down after it finished, or tell the movie player to launch (and loop) Winamp after the movie finishes. Or tell the CD Burner to shut down the machine once it's finished burning the disc. Or just tell Windows whenever any user-app finishes a large job, play an alarm, wait 30 seconds for cancelling then hibernate the machine.
This is just a single example of this kind of functionality, but it generalises to pretty much a new way of interacting with the computer - you aren't restricted to (automatic command-line scripting || interactive GUI) - you could have the best of both worlds, and mix them up however you like.
You should also be able to easily identify for each program/object which events/properties are available for scripting, and (ideally) have some kind of centralised and automatic documentation to make it easy to get started or look up less-common commands. Again, IIRC, DCOP allows for automatic listing of all the objects exposed by an app (from the console!), and while it lacks (again, IIRC) built-in documentation, you can work out how to do lots of things from the method/property names alone.
This is the kind of itch that people can easily scratch, and one which leads them into more hardcore development such as using (then writing) COM/Automation apps.
The original question I posed was about improvements over what we already have, to which someone replied maybe there weren't any improvements to make. This is just one example off the top of my head, and one which is (almost) completely unsupported by the platform/developers, but would lead to both a huge increase in usability, and smooth the learning-curve between "user" and "developer" (which "scripting" and "the web" have been doing for years).
"It wouldnt make sense to have automation default to enabled for all apps - it would just mean a lot of work required to write any application under VS, 90% of which wouldnt need it."
Why wouldn't it make sense to enable automation/scriptability for all apps? It would be a lot of work? That was kind of my point - it's not impossible, but it's a sufficient pain in the arse that people don't bother, so users suffer.
In an ideal world all apps would be scriptable like this, so the fact that programmers can't be bothered to add the support tells me it's still too onerous a task, hence my original point.
"Clearly, there is something that you are trying to do, but you are incapable, so you are having a rant at Microsoft, just because you can't manage to d
"No, Longhorn is going to be released in the future anyway so disappointing people early won't make much difference."
Yes it does. If people are looking forward to Longhorn they could delay it by another 6 months and people would still buy it in droves. If it's universally anticipated to be embarrassingly shite, initial uptake will be a fraction of what the want, and further delays could effectively kill it.
Sorry - should make clear - "we" was "the computing industry". I have no connection with Microsoft in any way, and that's just how I like it.
Re-reading it, it was a bit open to mis-interpretation;-)
But there's so much more that we could do with ordinary computing. I can think of half-a-dozen things we could be doing, without any trouble at all. Fuck Trusted Computing and DRM, and fuck sucking up to Big Content - whatever happened to genuine developments and refinements in basic computer use?
For just one example, where's the scriptability of compiled apps? I'm not talking about built-in VBA (hackcoughspit), but something more like Apple's system (SmallTalk? I dunno), or DCOP in KDE or GNOME (I forget which - a linux-based colleague once wowed me with how compiled, native, window-manager apps could be hooked by external scripts which received input and controlled the apps' behaviour.
Sure, ActiveX was a step in that direction, but it's not a "default" part of any Windows app - you have to code for it specifically and it's a nightmare. It's also a pile of shite, and insecure to boot.
I want to be able to write a script to hook when a certain colleague comes on-line in MSN Messenger, and automatically MSN him a file (fuck, I'd settle for only being alerted when someone from a certain group came on-line, but no-go). I want to be able to hook the end of a CD-burn and shutdown my machine. Or play a sound. I want to be able to script additional user-actions tied to a specific menu item in a specific program, or tied to a single menu item in every program that offers that menu item.
I know all these things can be done, either using kludgy workarounds, different apps or using VB/WSH/JS and ActiveX objects, but every solution is different. Nothing works the same. Most programs are entirely unscriptable, unless the programmer specifically tries to offer that functionality.
I want Visual Studio to expose DCOP-style scripting hooks for every app, unless you specifically turn it off (and even then, that shouldn't be easy). I want a proper, documented, sensible scripting language (or languages)..NET would look vaguely interesting, if it wasn't now an empty marketing catch-all buzzword for vendor lock-in. They could have done it right and created a genuinely next-generation interface, but instead it's late, buggy, ill-designed and ultimately just one more attempt to tie you to MS.
Sure, I can hear the calls now - "but users won't use those features - who even understands scripting apart from a few hackers, sysadmins and power users?"
But that's your fucking answer right there - the early adopters and pioneers, the people who advise on business-systems upgrades, and the people who bridge the gap and educate their fellow "ordinary users" so the skills trickle-down until everyone understands it. Fifteen years ago, who used and understood e-mail, or the internet? Hackers and sysadmins. And now?
Linux is successful because it's designed for hackers. Sure, it can be retrofitted for normal users too, but the reason it's still around is the thousands of hackers who tinker and play with it.
Microsoft is successful because of their enormous marketing budget, and their canny (and, to be fair, illegal) business practices. I'd even go so far as to say MS is successful in spite of their technology - it's generally inferior to FOSS, in my opinion, because they'll compromise on The Right Thing for marketing and vendor lock-in reasons.
If I were MS I'd be making my UI as scriptable and hackable as possible in an attempt to steal Linux's thunder. They've currently got the basic-user-desktop sewn up, although it's under attack from FLOSS. If they had any sense at all they'd be courting the hackers and power-users, to actually attack FLOSS where it hurt.
Is it just me, or is Longhorn increasingly beginning to resemble vapourware? We were sold the idea of a revolutionary next-gen computing platform, with all-new graphics subsystem, trusted computing (yuck, but at least different), enhanced security, relational filesystem, etc, etc, etc.
Now Avalon's being back-ported to XP, trusted computing isn't making it into the final product, WinFS has been pushed back to god-knows-when, and general security will likely be as god-awful and insecure as ever.
Against this background, what does Longhorn actually have to offer potential upgraders? Especially businesses?
Pretty Aero Glass UI? "Windows theme's always worked fine for us, thanks, and requires no user-retraining - why bother upgrading?"
But, it's all new! "Yeah, so we'll have to buy all-new hardware. And beta test it^W^W^W live with the inevitable but unfortunate 1.0 bugs.
Increasingly the reasons are "But, but, but, it's the new operating system from MS - you have to upgrade!", which is, obviously, no reason at all.
I was quite worried about LH when it was first announced - it sounded like a hell of a leap beyond anything Linux and Free Software had to offer (although, given time, I was sure FLOSS would catch up or surpass it).
Now, however, I'm having trouble retaining even mild interest - Microsoft hyped it so much, and are now so publicly failing to deliver on anything they've promised, that by the time it launches I wouldn't be surprised if they've Daikatana'd the thing practically to death.
Longhorn? Long-in-the-tooth, more like - a decrepit and crumbling shadow of it's former self that looks in danger of becoming irrelevent before it's even launched.
Of course, I may be condemning it unfairly here - are there any killer features that will save it from this downward trajectory?
Really? I understood the whole episode to be a superbly-constructed allegory on the ultimately self-destructive nature of violent antisocial behaviour, with a side-moral on the dangers of hubris and the essential importance of external affirmation as an error-preventative strategy... or something...:-\
(Yeah, ok, I used to date a Lit Crit major. And you've obviously never handed in a paper on Postmodernism, either - your post was a feasible, intelligible and practically credible treatise. This is Postmodernism - You don't get points for being right, you know, just for being clever).
Right, and that would have been roundly shouted down as nothing more than a Slashvertisement, by people such as yourself... "Facts" isn't equivalent to "news". In fact, for the ininitiated, (accurate) context and commentary can be as important than the unvarnished facts, because facts can be misleading:
"Real Offers 25 Free Songs Per Month!"
To my elderly maiden Aunt (or any fuckwit who doesn't bother to RTFA), that probably sounds like a great deal.
To anyone who knows Rhapsody, or who actually reads the article, we know what a crock of shit the offer is, so commentary is irrelevent at worst.
By including some commentary in the article you avoid some naive mis-interpretations, and (hopefully) reduce the size of the peanut gallery when it comes to reading comments on the story.
True, the submitter did lay it on a bit thick, but then so did Real - what the fuck was all that lead-in hype from Real about a revolution in ditigal music to compare with the advent of streaming? From here it looks like an overhyped, shitty offer to naive users to prop up a failing business model.
Yeah, I did. Obviously it's hard to be sure, but:
1) I've heard/read from many other sources that this isn't the case.
2) "We'd say after 5000 to 8000 years of tea drinking, you'd have to assume that tannins can't be all that bad" doesn't sound too authoritative to me. Shit, as a species we've been smoking tobacco for thousands of years, so that must be safe too, right?
3) Tannins are the plant's way of detering animals from eating them. You'd think that the chemical used would have some kind of negative effect, or where's the mileage in wasting good growing-energy producing and refining them?
4) Dammit, the tea just tastes nicer with it!
Actually, you couldn't ever copy tapes, either - it was totally illegal in exactly the same way that copying CDs is.
I mean, ok, do everyone and his brother used to copy tapes for each other, but that doesn't mean you "could", just that the RIAA weren't so eager to hunt you down and persecute (sorry: prosecute) you for it as they are now.
The problem is that with the advent of digital music, music is just "software" - it's all just 1s and 0s, and you can (theoretically) copy them perfectly without degradation.
For the record, I agree with your sentiment - if you buy a copy of something (even something digital) you should own that copy, and be free to do whatever you like with it within Fair Use - make backups, mashups, trans-code it, extract excerpts, make mix-tapes for personal use, whatever you like.
At the moment the music industry (and software industry, I'm looking at you too) is unfairly sitting on the fence on this issue - either we (as consumers) are:
Buying something, in which case they have no right whatsoever to tell us how (or restrict how) we subsequently use it (including re-sale!), or
Licensing something, in which case I'd like replacements for all the CDs I've had die on me over the years. After all, I'm just "licensing the song", right? Not "buying the CD"...
When you're drinking black (Indian) tea (not green tea, as in the far east and parts of Greece/turkey), it tastes unpleasantly bitter without milk (even with sugar).
Indian tea also has an awful lot of tannins in (the stuff produced by many plants to ward off predators from unripe fruit). These are moderately bad for you, and adding milk mops up the tannins, leaving a less-bitter and healthier drink.
That's very interesting information - let's look at these similarities:
1. The data stream is segmentated into runs of the most common symbol.
What, like run-length-encoding?... which has been around for ever, and is pretty much the simplest compression algorithm known to man. Hmmm, original...
2. Each run is characterized by a pair of symbols (n, a) with n indicating the length of the run and a information about the next symbol delimiting the run. This extends all the way to the last symbol.
Again: what, like run-length-encoding?
3. The remaining information is encoded using a special codebook.
Not entirely sure about this, but it doesn't sound excessively difficult or clever. It sounds kind of general and catch-all. In fact, the very generality of the statement suggests to me they use (or construct) their codebooks in different ways.
4. Runs of the most common symbol that reach all the way to the end of the block are encoded using the special EOB symbol.
Right, so (a,-1) means "a until the end of the block", rather than wasting bits specifying exactly how many times to repeat the character (a,1633069832)? Well, I hate to say it, but this does seem... kind of... obvious?
5. The codestream rewritten using the codebook is finally Huffman entropy encoded.
Right, and do they own the patent on Huffman entropy encoding? If so, I'll cheerfully sit down and shut up, if not, can it really be a point against JPEG that they use the same algorithm as Forgent's process, if Forgent doesn't own a patent on it?
I'm presuming these are abridged similarities between the Forgent and JPEG methods, or that there's some Deep Magic in the codebook step, because otherwise this looks depressingly uninventive and non-obvious...
Given the overwhelming happiness of naive consumers to use electronics with (even highly restrictive) DRM built-in (Napster-2-Go, iTunes, any non-native-MP3 digital music player), where is the pressure against strong IP laws going to come from?
Strong IP laws allow electronics manufacturers to make it harder for third parties to interoperate with their kit, thereby increasing vendor lock-in (and hence, their profits - iTunes makes a loss, iPod rakes in money hand-over-fist).
Weak IP means they can't stop people reverse-engineering their protocols and products and people can release cheap but interoperable knock-offs, which undercut their market and prevent lock-in.
Were I a consumer electronics manufacturer, I'd be lining up behind strong IP as far as I could - it would be all pro and no con, as far as I could see.
Well, plenty of research does get done in industry, but yes, academia does represent an essential (and open) source of new developments and theories, so I might have gone a tad overboard in the heat of composition;-)
Something of a pet peeve of mine though (in case anyone couldn't tell...;-)
Actually, it doesn't say that at all - it merely tells you that "the computer-generated scores count for about a third to a quarter of students' final grade for Brent's class".
That's the overall class ("course" or "module" for us Brits) - no mention of how those scores get in there. In fact, if it was used to generate a fraction-of-each-paper score you'd expect them to say "count for 1/3 to 1/4 of each paper". Giving a proportion of the final grade for the class suggests that there are several software-marked-only papers, and that is indeed how I read it.
They do say the students can access the system on the web, but nowhere does it say the system doesn't give the paper's final score, too.
Sarcasm like this saved Oscar_Wilde over 3 minutes of not READING THE FUCKING ARTICLE properly. If he didn't want to read and assimilate articles -- he's in the wrong line of nit-picking. End of story, finish him.;-p
"I have lots of programs that save me hours of "doing my fucking job". They're called scripts, and it's called efficiency."
But you're obviously a sysadmin or similar - your job is to use a deterministic tool to solve a single problem. A professor is a teacher - his job is to train an unherently unreliable chaotic entity to do something they have no prior experience of doing.
All you have to do is give the right instructions and the computer will be the perfect pupil (or nearly so) - it's essentially deterministic.
A professor has to give perfect instructions, then pick up the pieces and correct the student when they get it wrong because they forgot/misunderstood/didn't listen/weren't at a lecture/etc. Without that essential explanation how are the students supposed to learn?
"If I can write a program to automate a menial task so I don't have to do it, then by all means, I should do it. If grading undergrad papers is a menial task that can be automated, then it should be automated."
But, but, but, grading isn't a menial task - it should be the single most important thing in a professor's job desciption. Honestly, name me one thing more important that a professor does than training the next generation of people in his/her field. There is nothing more important, because if they didn't do this the entire field would die with them.
Professor should not be hired to churn out research papers or novels, or to go to symposia or meetings, or to sit in their offices and contemplate their navels all day - they should be employed to teach fucking students. Anything else is a pleasant distraction from their essential role in society.
Apologies if this position seems a little aggressive, but I went to a university where CompSci professors were chosen based on their ability to churn out papers and make the department look good, and it was a fucking disgrace. Lecturers who couldn't speak english, lecturers who were using six-year-old out-of-date teaching materials because they couldn't be bothered to write new ones, and worst of all, professors who treated their students as nothing more than an annoying distraction from their pet projects.
"I mean, just because a freshman writes a bad paper doesn't mean a professor has to actually read it."
Right, and just because your compiler throws errors doesn't mean you have to fix them, but don't expect your program to work for shit unless you complete the feedback loop and correct your program.
You know, the more I think of it, the more I suspect I might have just been trolled. If not, hope this gives food for thought. If so, well done sir - I haven't been successfully trolled for years.
My apologies, but the details of this exploit were linked-to in a previous article as well as this one, and you can't move for explanations of how it works. I also tend to get irritable with people who, when explicitely presented with information on a subject, can't be bothered to even attempt reading it (as the GP obviously hasn't, obviously not understanding the first thing about how it works), and instead just want everyone to explain it for them (again).
What is really going on has nothing to do with 302, or at least very little. What these people are doing is to set up fake web sites using content filched from genuine Web sites. This allows (or is beleived to allow) them to climb the google rankings.
Nope. They're using a combination of 302 HTTP response headers and a bug/misfeature in Google's spidering system - they don't have to have any kind of access to the site being hijacked, and they aren't copying anything off the site. They set up a 302 redirect to the hijackee, and Google itself gets confused and attributes the hijackee's content to the hijacker.
This is all explained in the article, although since you apparently haven't understood it either I accept it might be badly-written and/or overly technical;-)
I don't see why someone would use a 302 response when they can just copy the entire content unless there is some sort of bug in Google's pagerank that is not being explained. Copying the entire content is much simpler.
This way they aren't just hosting the same content as another site (competing for rankings and leaving themselves open to accusations of copyright violation), they're actually knocking the original site out of the Google rankings altogether, in a pretty subtle way (so it might even go unnoticed by the site owner), with very little work (esp. compared to replicating a whole page/site), and without explicitely violating any laws (that I can see).
So what the attacker does is to set up their site so that when the googlebot comes round it publishes some legitimate content, then when other folk follow the site from a google search they get pages infested with spyware or the like.
Not quite - this is common-or-garden (and long-known-about) page cloaking, which is a pain in the arse, but you can live with it. What the article is talking about is entirely different (see above).
I can't foresee any occasion where I'd accept DRM, ever. Allow me to explain:
DRM only works if it's supported right down to the hardware, and I fundamentally object to my computer having a different agenda to mine. I will not buy hardware that I'm not in control of, and I view it as irresponsible and invasive to even try to control or artificially limit something I've paid (my) good money for.
If you don't understand this attitude, ask yourself why the government fines people for speeding but doesn't install mandatory speed-limiters in cars, or makes murder illegal but doesn't ban guns outright. Precedents both.
DRM without end-to-end hardware support is essentially impotent unless you are prohibited from cracking it by law. Legislating against technology like this is like legislating against bad weather, or against the tide - it's coming eventually whether you like it or not, and you only look stupid and/or put yourself in harm's way by trying to get between it and where it's going.
(As an aside, can anyone think of an example where a popular technology has been legislated against, and it's died there and then? I honestly can't think of one. In contrast, I can think of several cases where legal proceedings (and the attendant publicity) have launched a new piece of techology into mainstream usage, but I can't think of one counterexample. If anyone else can, please let me know...)
Short version - end-to-end DRM is fundamentally invasive and tramples on your rights as a consumer (First Sale, Fair Use, etc). Vulnerable DRM propped up by dubious lawmaking both cheapens the law and retards technology as a whole (e.g. banning P2P networks unless they pro-actively filter for copyrighted software effectively bands P2P as a useful technology).
DRM represents an attempt to graft concepts and precedent from physical property law onto digital "property". They are not alike, and this sets a false precedent which will (and is) harming both our technological and cultural development.
Yeah, I saw the article, but didn't read up on the in-depth details of how it worked at the time. Anyway...
1) The Java Community provide an OS dependent security call for the JVM to make that would make contents available to any available AV software for inspection.
This still doesn't solve the problem of encryption (even something as simple as XORing). The problem is recognising native executable code as different from JVM bytecode, when all you're looking at is essentially a string of (optionally encrypted) characters. IIRC, you'd have to make the.jar's contents available and crack any encryption or it'd be essentially worthless.
2) Monitor calls that create or rename system files. This would be monitoring data flowing through JNI, and would be monitoring for and either disallow or request permission with specific file names OS dependent commands to create or rename files to executable extensions. This is native direct OS API stuff, not trying to determine what any program called might do.
Granted, this has a chance of working, but it would be a bit of a nightmare to keep the list of "executable files" up-to-date - straight off the top of my head I can think of exe, com, bat, vbs, js, wsh, pif, cmd and lnk files - any of which can be used to create or somehow launch executable code (and microsoft do seem to like frequently creating new executable types).
Assuming the list is kept up-to-date asking the user before creating or opening any of these filetypes would work, but you'd have to be careful to make the user understand what was happening, and we'd essentially end up with the same problem as before - user blithely clicks "yes" and the whole thing unravels...
The major problem is the naive user is in the loop. The "Firefox exploit" (sic) worked because the user didn't know any better than to click "yes, I trust this company" - replacing this simple question with a slightly more complex one ("yes, I trust this company to download/open/rename this file to that filename") doesn't stop the problem. If anything it only make it worse (since in my experience if a user doesn't understand a question they tend to just hit "yes").
Basically, to avoid naive user attacks you need to
1) Educate the user (not likely, at least in the short term - classic users are lazy and stupid), or
2) Take the naive user out of the loop - have some automatic way of detecting and preventing the exploit, so a naive user can't drop their spyware defences.
You can't fix a social exploit without educating the user or taking him out of the loop...
Slashdot Mirror
Better still, use this site to find any number string in the first 200,000,000 digits of pi:
http://www.angio.net/pi/piquery
I call BS on this whole article. It's exactly the kind of thing I hear (with minor variations) from anyone who's not into computer gaming, especially those too old to have started as kids.
"Am I the only one who expects a collapse of the gaming business soon? Does anyone else think that it is overdue? It has happened before,"
When, exactly? When was computer gaming ever as big as it is now, and when did it subsequently collapse? And even if it did, the fact that it's back and as big as it is now downgrades that from a "collapse" to a "temporary dip".
"and I can't see how people will keep shelling out $50 or so for a video game when the games have hardly changed since the invention of the first-person shooter."
So when did that ever matter? There are about five-ten genres of games, and there are already one or more examples which are considered pretty definitive, or were at the time (shooters = Half-Life 2, RTS = Dune/C&C/Total Annihilation, Point-and-Click Adventure = Sam&Max/Curse of Monkey Island, etc).
Having these definitive games around didn't stop people producing new (and better/more complex/more involving) ones, did it? The point is the differences between the games, not the similarities.
And ok, $50 is a lot for a game, and we'd all like it if it was cheaper. But you'll pay $15 for a DVD, and that lasts a tiny fraction of the time a good game does.
"I complain to my kids about this, and they insist that things have changed markedly. They show me examples, and all I see are tweaks and weirder, mostly stupid weapons."
Yeah. But what they're showing you is new gameplay dynamics, improved graphics, better immersion and a more engaging storyline, you inattentive and obdurate prat.
"There are four or five simple game categories and nothing really new or different."
Ignoring the conservative "genre" number... Yeah, and before Dune/C&C there would have been four game categories, until someone invented one. But you can't do that forever - at some point someone will have tried every game-style worth playing, and the only thing to do is to make them technically better, and more involving.
Let's face it - as Aristotle thought, practically every movie can be broken down into the basic "initial balance/disruption of balance/re-establishment of balance" structure. Does this mean that every movie is the same? So should the movie industry collapse? No, because what's important is not the details of how you interact with the film, but the story the film tells.
Likewise, computer gaming is moving away from frantic innovation in how you interact with the game, more towards cinematic, immersive stories. That's evolution, not death.
"When my kids show me a game, I usually say that it's nothing but the same old running-jumping-kicking-shooting with a new background."
Bingo - that's because you're old, out-of-touch and writing an article on something about which you know nothing. Show me a Bollywood movie and all I see is a lot of silly dancing-annoying music-cheesy-plot twists with new costumes, but I don't assume that the entire Bollywood movie industry is without artistic merit and destined to die on its arse. That's because I don't have my head jammed up my arse, and don't assume that "I don't understand" = "Contains no merit whatsoever".
"in almost all the big games, the so-called boss characters are all beginning to be pretty much the same: big, creepy monsters."
Apart from the ones which are big, creepy robots. Or large, tough fighters. Or large numbers of smaller weaker units working together, or...
Actually, John, they're just tougher challenges and moments of heightened tension, and it so happens that often equates to "bigger and creepier". But not always.
"If you want to see... how inane this is... rent... Starship Troopers... It's essentially a video game turned
But why is this? I was under the impression that this was the reason DirectX existed - to abstract the interface form the hardware, so developing for the PC was more like developing for a console.
These days, with the availability of high-level APIs, does this excuse really stack up? Or is it just a convenient games-industry euphamism for "Microsoft kept throwing money at us until we agreed"?
I agree - COM is interesting, but it's event-driven reactivity I'm really interested in. We've already got at least two different ways to instruct another app what to do (windowmessages and COM) - I want a third-party app to report back to me what it's doing/done so I can decide what to tell it next.
You're pretty close to what I originally envisaged with your last sentance, but I was thinking more along the lines of:
1) Set a CD burning in Nero (or whatever).
2) Hook the "I'm finished" event throught the gui - either the CD Burner gives you a list of exposed high-level events, or maybe Ctrl+Alt+Right-click on the progress bar to set it at the widget level.
3) Select the OnBurnFinished()/ProgressBar.OnChange() event (depending how it's exposed in 2) and add the body of the function:
onChange(float status)
{
if(status==1)
System.Shutdown();
}
And click ok.
Obviously this is a very rough idea, but it adds a huge level of usability to the system (far beyond just being able to effectively script apps in batch-mode), and I can't see any show-stopping problems that would prevent it from being practical...
Well, the idea would be that as much of the setup as possible would be offloaded onto the framework/IDE (Visual Studio, or whatever) - developers are inherently lazy (I know, I am one), and advanced usability like this just isn't considered enough of a priority (yet) to bother expending any effort on it. If it would work it'd have to be something that came essentially "for free" with the framework, unless we're going to see a revolution in the direction of semantic app development, like we've seen in web development (unlikely).
.NET apps were phased in. Having the platform handle most/all of the work also means that to upgrade your existing program all you'd have to do is recompile it. Ok, Win API stuff would be a re-writing nightmare, but this kind of scriptability as an extension to the MFC or .NET platforms? Should be fairly easy.
;-)
Obviously the programmer would still have to identify scenarios where you'd want app-specific stuff, but I can see many useful (and general) cases where it could be automated - how about having a scriptable "progress bar reached 100%" event? Although there are obvious issues still to resolve, this would essentially allow you to attach events to media players finishing tracks, CD burners finishing burns, etc, etc, etc, all from one small (automatic) change, at the widget level.
Scriptability on a per-application basis would do as a beginning, although obviously ideally every app would be scriptable. Mind you, this could be phased in gradually in a per-app basis, much as MFC or
Backwards compatability shouldn't be a problem - new apps expose the new interface, and old apps don't. Just like COM/ActiveX/Automation/whatever. Of course, that makes old apps less useful/usable, but that only gently encourages people to update them...
Yeah, I use Nero, and love that bit of functionality. In fact, the original thought came from the frustration that every app didn't offer that kind of option, and wondering why there wasn't a more general way to specify advanced behaviours like "shutdown when finished"...
A few years ago I actually hacked up a vaguely similar system from the "other side" - it allowed you to select a window with the mouse, grabbed a window handle to it and allowed you to write scripts to send windowmessages to that window. Once attached to a window the scripts could be fired however you wanted (I only got as far as writing a voice control front-end in the end).
What we're talking about here is competing the loop - having the app itself expose events (report status) back so it can trigger behaviour in other programs, rather than just executing windowmessages (following instructions) sent to it.
You know, the more I think about this, the more tempted I am to see if it's possible to go anywhere with this...
I'm well aware of COM (despite, I admit, not having written large numbers of COM apps), and yes, it does provide a good start. However, it's also several years old, and ActiveX (the closest thing we've had to an update) is in many ways (security?) a giant leap backward.
Granted, OLE/COM has many benefits (and does, for example, offer clipboard functionality second-to-none), but I wasn't really talking about accessing and manipulating the deep-internal data structures of a program. Windows (with COM) already has this pretty much down-pat (assuming the original coder thought to provide the opportunity), but this is only really of much use to "Windows Developers" and hardcore sysadmins.
I was talking more about quick, easy scripting of user-interface functionality - extending what we've got from "internal data structures" (as a lot of COM/ActiveX objects are concerned with) to things that actually matter to normal users
For example, I frequently set a CD burning (or music/movie playing, or download going), then go to bed/go out/do something else. Why can't I call up (in the UI) a simple list of all the events the program exposes, and attach a short script to an "I'm finished processing" one? This event could be fired by any app which had a "single large job" to do - burning a CD for CD burners, reaching the end of a movie/playlist for media players, transcoding a file in a DVD ripper/converter, etc.
I could tell winamp to shut down after it finished, or tell the movie player to launch (and loop) Winamp after the movie finishes. Or tell the CD Burner to shut down the machine once it's finished burning the disc. Or just tell Windows whenever any user-app finishes a large job, play an alarm, wait 30 seconds for cancelling then hibernate the machine.
This is just a single example of this kind of functionality, but it generalises to pretty much a new way of interacting with the computer - you aren't restricted to (automatic command-line scripting || interactive GUI) - you could have the best of both worlds, and mix them up however you like.
You should also be able to easily identify for each program/object which events/properties are available for scripting, and (ideally) have some kind of centralised and automatic documentation to make it easy to get started or look up less-common commands. Again, IIRC, DCOP allows for automatic listing of all the objects exposed by an app (from the console!), and while it lacks (again, IIRC) built-in documentation, you can work out how to do lots of things from the method/property names alone.
This is the kind of itch that people can easily scratch, and one which leads them into more hardcore development such as using (then writing) COM/Automation apps.
The original question I posed was about improvements over what we already have, to which someone replied maybe there weren't any improvements to make. This is just one example off the top of my head, and one which is (almost) completely unsupported by the platform/developers, but would lead to both a huge increase in usability, and smooth the learning-curve between "user" and "developer" (which "scripting" and "the web" have been doing for years).
"It wouldnt make sense to have automation default to enabled for all apps - it would just mean a lot of work required to write any application under VS, 90% of which wouldnt need it."
Why wouldn't it make sense to enable automation/scriptability for all apps? It would be a lot of work? That was kind of my point - it's not impossible, but it's a sufficient pain in the arse that people don't bother, so users suffer.
In an ideal world all apps would be scriptable like this, so the fact that programmers can't be bothered to add the support tells me it's still too onerous a task, hence my original point.
"Clearly, there is something that you are trying to do, but you are incapable, so you are having a rant at Microsoft, just because you can't manage to d
"No, Longhorn is going to be released in the future anyway so disappointing people early won't make much difference."
Yes it does. If people are looking forward to Longhorn they could delay it by another 6 months and people would still buy it in droves. If it's universally anticipated to be embarrassingly shite, initial uptake will be a fraction of what the want, and further delays could effectively kill it.
Sorry - should make clear - "we" was "the computing industry". I have no connection with Microsoft in any way, and that's just how I like it. Re-reading it, it was a bit open to mis-interpretation ;-)
But there's so much more that we could do with ordinary computing. I can think of half-a-dozen things we could be doing, without any trouble at all. Fuck Trusted Computing and DRM, and fuck sucking up to Big Content - whatever happened to genuine developments and refinements in basic computer use?
.NET would look vaguely interesting, if it wasn't now an empty marketing catch-all buzzword for vendor lock-in. They could have done it right and created a genuinely next-generation interface, but instead it's late, buggy, ill-designed and ultimately just one more attempt to tie you to MS.
For just one example, where's the scriptability of compiled apps? I'm not talking about built-in VBA (hackcoughspit), but something more like Apple's system (SmallTalk? I dunno), or DCOP in KDE or GNOME (I forget which - a linux-based colleague once wowed me with how compiled, native, window-manager apps could be hooked by external scripts which received input and controlled the apps' behaviour.
Sure, ActiveX was a step in that direction, but it's not a "default" part of any Windows app - you have to code for it specifically and it's a nightmare. It's also a pile of shite, and insecure to boot.
I want to be able to write a script to hook when a certain colleague comes on-line in MSN Messenger, and automatically MSN him a file (fuck, I'd settle for only being alerted when someone from a certain group came on-line, but no-go). I want to be able to hook the end of a CD-burn and shutdown my machine. Or play a sound. I want to be able to script additional user-actions tied to a specific menu item in a specific program, or tied to a single menu item in every program that offers that menu item.
I know all these things can be done, either using kludgy workarounds, different apps or using VB/WSH/JS and ActiveX objects, but every solution is different. Nothing works the same. Most programs are entirely unscriptable, unless the programmer specifically tries to offer that functionality.
I want Visual Studio to expose DCOP-style scripting hooks for every app, unless you specifically turn it off (and even then, that shouldn't be easy). I want a proper, documented, sensible scripting language (or languages).
Sure, I can hear the calls now - "but users won't use those features - who even understands scripting apart from a few hackers, sysadmins and power users?"
But that's your fucking answer right there - the early adopters and pioneers, the people who advise on business-systems upgrades, and the people who bridge the gap and educate their fellow "ordinary users" so the skills trickle-down until everyone understands it. Fifteen years ago, who used and understood e-mail, or the internet? Hackers and sysadmins. And now?
Linux is successful because it's designed for hackers. Sure, it can be retrofitted for normal users too, but the reason it's still around is the thousands of hackers who tinker and play with it.
Microsoft is successful because of their enormous marketing budget, and their canny (and, to be fair, illegal) business practices. I'd even go so far as to say MS is successful in spite of their technology - it's generally inferior to FOSS, in my opinion, because they'll compromise on The Right Thing for marketing and vendor lock-in reasons.
If I were MS I'd be making my UI as scriptable and hackable as possible in an attempt to steal Linux's thunder. They've currently got the basic-user-desktop sewn up, although it's under attack from FLOSS. If they had any sense at all they'd be courting the hackers and power-users, to actually attack FLOSS where it hurt.
Build it and they will come.
Is it just me, or is Longhorn increasingly beginning to resemble vapourware? We were sold the idea of a revolutionary next-gen computing platform, with all-new graphics subsystem, trusted computing (yuck, but at least different), enhanced security, relational filesystem, etc, etc, etc.
Now Avalon's being back-ported to XP, trusted computing isn't making it into the final product, WinFS has been pushed back to god-knows-when, and general security will likely be as god-awful and insecure as ever.
Against this background, what does Longhorn actually have to offer potential upgraders? Especially businesses?
Pretty Aero Glass UI? "Windows theme's always worked fine for us, thanks, and requires no user-retraining - why bother upgrading?"
But, it's all new! "Yeah, so we'll have to buy all-new hardware. And beta test it^W^W^W live with the inevitable but unfortunate 1.0 bugs.
Increasingly the reasons are "But, but, but, it's the new operating system from MS - you have to upgrade!", which is, obviously, no reason at all.
I was quite worried about LH when it was first announced - it sounded like a hell of a leap beyond anything Linux and Free Software had to offer (although, given time, I was sure FLOSS would catch up or surpass it).
Now, however, I'm having trouble retaining even mild interest - Microsoft hyped it so much, and are now so publicly failing to deliver on anything they've promised, that by the time it launches I wouldn't be surprised if they've Daikatana'd the thing practically to death.
Longhorn? Long-in-the-tooth, more like - a decrepit and crumbling shadow of it's former self that looks in danger of becoming irrelevent before it's even launched.
Of course, I may be condemning it unfairly here - are there any killer features that will save it from this downward trajectory?
Besides a billion-dollar marketing budget?
Really? I understood the whole episode to be a superbly-constructed allegory on the ultimately self-destructive nature of violent antisocial behaviour, with a side-moral on the dangers of hubris and the essential importance of external affirmation as an error-preventative strategy... or something... :-\
(Yeah, ok, I used to date a Lit Crit major. And you've obviously never handed in a paper on Postmodernism, either - your post was a feasible, intelligible and practically credible treatise. This is Postmodernism - You don't get points for being right, you know, just for being clever ).
Right, and that would have been roundly shouted down as nothing more than a Slashvertisement, by people such as yourself... "Facts" isn't equivalent to "news". In fact, for the ininitiated, (accurate) context and commentary can be as important than the unvarnished facts, because facts can be misleading:
"Real Offers 25 Free Songs Per Month!"
To my elderly maiden Aunt (or any fuckwit who doesn't bother to RTFA), that probably sounds like a great deal.
To anyone who knows Rhapsody, or who actually reads the article, we know what a crock of shit the offer is, so commentary is irrelevent at worst.
By including some commentary in the article you avoid some naive mis-interpretations, and (hopefully) reduce the size of the peanut gallery when it comes to reading comments on the story.
True, the submitter did lay it on a bit thick, but then so did Real - what the fuck was all that lead-in hype from Real about a revolution in ditigal music to compare with the advent of streaming? From here it looks like an overhyped, shitty offer to naive users to prop up a failing business model.
Mmmm... revolutionary... <:-)
Yeah, I did. Obviously it's hard to be sure, but: 1) I've heard/read from many other sources that this isn't the case. 2) "We'd say after 5000 to 8000 years of tea drinking, you'd have to assume that tannins can't be all that bad" doesn't sound too authoritative to me. Shit, as a species we've been smoking tobacco for thousands of years, so that must be safe too, right? 3) Tannins are the plant's way of detering animals from eating them. You'd think that the chemical used would have some kind of negative effect, or where's the mileage in wasting good growing-energy producing and refining them? 4) Dammit, the tea just tastes nicer with it!
Actually, you couldn't ever copy tapes, either - it was totally illegal in exactly the same way that copying CDs is.
I mean, ok, do everyone and his brother used to copy tapes for each other, but that doesn't mean you "could", just that the RIAA weren't so eager to hunt you down and persecute (sorry: prosecute) you for it as they are now.
The problem is that with the advent of digital music, music is just "software" - it's all just 1s and 0s, and you can (theoretically) copy them perfectly without degradation.
For the record, I agree with your sentiment - if you buy a copy of something (even something digital) you should own that copy, and be free to do whatever you like with it within Fair Use - make backups, mashups, trans-code it, extract excerpts, make mix-tapes for personal use, whatever you like.
At the moment the music industry (and software industry, I'm looking at you too) is unfairly sitting on the fence on this issue - either we (as consumers) are:
Buying something, in which case they have no right whatsoever to tell us how (or restrict how) we subsequently use it (including re-sale!), or
Licensing something, in which case I'd like replacements for all the CDs I've had die on me over the years. After all, I'm just "licensing the song", right? Not "buying the CD"...
When you're drinking black (Indian) tea (not green tea, as in the far east and parts of Greece/turkey), it tastes unpleasantly bitter without milk (even with sugar).
Indian tea also has an awful lot of tannins in (the stuff produced by many plants to ward off predators from unripe fruit). These are moderately bad for you, and adding milk mops up the tannins, leaving a less-bitter and healthier drink.
That's very interesting information - let's look at these similarities:
... which has been around for ever, and is pretty much the simplest compression algorithm known to man. Hmmm, original...
1. The data stream is segmentated into runs of the most common symbol.
What, like run-length-encoding?
2. Each run is characterized by a pair of symbols (n, a) with n indicating the length of the run and a information about the next symbol delimiting the run. This extends all the way to the last symbol.
Again: what, like run-length-encoding?
3. The remaining information is encoded using a special codebook.
Not entirely sure about this, but it doesn't sound excessively difficult or clever. It sounds kind of general and catch-all. In fact, the very generality of the statement suggests to me they use (or construct) their codebooks in different ways.
4. Runs of the most common symbol that reach all the way to the end of the block are encoded using the special EOB symbol.
Right, so (a,-1) means "a until the end of the block", rather than wasting bits specifying exactly how many times to repeat the character (a,1633069832)? Well, I hate to say it, but this does seem... kind of... obvious?
5. The codestream rewritten using the codebook is finally Huffman entropy encoded.
Right, and do they own the patent on Huffman entropy encoding? If so, I'll cheerfully sit down and shut up, if not, can it really be a point against JPEG that they use the same algorithm as Forgent's process, if Forgent doesn't own a patent on it?
I'm presuming these are abridged similarities between the Forgent and JPEG methods, or that there's some Deep Magic in the codebook step, because otherwise this looks depressingly uninventive and non-obvious...
Given the overwhelming happiness of naive consumers to use electronics with (even highly restrictive) DRM built-in (Napster-2-Go, iTunes, any non-native-MP3 digital music player), where is the pressure against strong IP laws going to come from?
Strong IP laws allow electronics manufacturers to make it harder for third parties to interoperate with their kit, thereby increasing vendor lock-in (and hence, their profits - iTunes makes a loss, iPod rakes in money hand-over-fist).
Weak IP means they can't stop people reverse-engineering their protocols and products and people can release cheap but interoperable knock-offs, which undercut their market and prevent lock-in.
Were I a consumer electronics manufacturer, I'd be lining up behind strong IP as far as I could - it would be all pro and no con, as far as I could see.
Well, plenty of research does get done in industry, but yes, academia does represent an essential (and open) source of new developments and theories, so I might have gone a tad overboard in the heat of composition ;-)
;-)
Something of a pet peeve of mine though (in case anyone couldn't tell...
Actually, it doesn't say that at all - it merely tells you that "the computer-generated scores count for about a third to a quarter of students' final grade for Brent's class".
;-p
That's the overall class ("course" or "module" for us Brits) - no mention of how those scores get in there. In fact, if it was used to generate a fraction-of-each-paper score you'd expect them to say "count for 1/3 to 1/4 of each paper". Giving a proportion of the final grade for the class suggests that there are several software-marked-only papers, and that is indeed how I read it.
They do say the students can access the system on the web, but nowhere does it say the system doesn't give the paper's final score, too.
Sarcasm like this saved Oscar_Wilde over 3 minutes of not READING THE FUCKING ARTICLE properly. If he didn't want to read and assimilate articles -- he's in the wrong line of nit-picking. End of story, finish him.
"I have lots of programs that save me hours of "doing my fucking job". They're called scripts, and it's called efficiency."
But you're obviously a sysadmin or similar - your job is to use a deterministic tool to solve a single problem. A professor is a teacher - his job is to train an unherently unreliable chaotic entity to do something they have no prior experience of doing.
All you have to do is give the right instructions and the computer will be the perfect pupil (or nearly so) - it's essentially deterministic.
A professor has to give perfect instructions, then pick up the pieces and correct the student when they get it wrong because they forgot/misunderstood/didn't listen/weren't at a lecture/etc. Without that essential explanation how are the students supposed to learn?
"If I can write a program to automate a menial task so I don't have to do it, then by all means, I should do it. If grading undergrad papers is a menial task that can be automated, then it should be automated."
But, but, but, grading isn't a menial task - it should be the single most important thing in a professor's job desciption. Honestly, name me one thing more important that a professor does than training the next generation of people in his/her field. There is nothing more important, because if they didn't do this the entire field would die with them.
Professor should not be hired to churn out research papers or novels, or to go to symposia or meetings, or to sit in their offices and contemplate their navels all day - they should be employed to teach fucking students. Anything else is a pleasant distraction from their essential role in society.
Apologies if this position seems a little aggressive, but I went to a university where CompSci professors were chosen based on their ability to churn out papers and make the department look good, and it was a fucking disgrace. Lecturers who couldn't speak english, lecturers who were using six-year-old out-of-date teaching materials because they couldn't be bothered to write new ones, and worst of all, professors who treated their students as nothing more than an annoying distraction from their pet projects.
"I mean, just because a freshman writes a bad paper doesn't mean a professor has to actually read it."
Right, and just because your compiler throws errors doesn't mean you have to fix them, but don't expect your program to work for shit unless you complete the feedback loop and correct your program.
You know, the more I think of it, the more I suspect I might have just been trolled. If not, hope this gives food for thought. If so, well done sir - I haven't been successfully trolled for years.
My apologies, but the details of this exploit were linked-to in a previous article as well as this one, and you can't move for explanations of how it works. I also tend to get irritable with people who, when explicitely presented with information on a subject, can't be bothered to even attempt reading it (as the GP obviously hasn't, obviously not understanding the first thing about how it works), and instead just want everyone to explain it for them (again).
;-)
What is really going on has nothing to do with 302, or at least very little. What these people are doing is to set up fake web sites using content filched from genuine Web sites. This allows (or is beleived to allow) them to climb the google rankings.
Nope. They're using a combination of 302 HTTP response headers and a bug/misfeature in Google's spidering system - they don't have to have any kind of access to the site being hijacked, and they aren't copying anything off the site. They set up a 302 redirect to the hijackee, and Google itself gets confused and attributes the hijackee's content to the hijacker.
This is all explained in the article, although since you apparently haven't understood it either I accept it might be badly-written and/or overly technical
I don't see why someone would use a 302 response when they can just copy the entire content unless there is some sort of bug in Google's pagerank that is not being explained. Copying the entire content is much simpler.
This way they aren't just hosting the same content as another site (competing for rankings and leaving themselves open to accusations of copyright violation), they're actually knocking the original site out of the Google rankings altogether, in a pretty subtle way (so it might even go unnoticed by the site owner), with very little work (esp. compared to replicating a whole page/site), and without explicitely violating any laws (that I can see).
So what the attacker does is to set up their site so that when the googlebot comes round it publishes some legitimate content, then when other folk follow the site from a google search they get pages infested with spyware or the like.
Not quite - this is common-or-garden (and long-known-about) page cloaking, which is a pain in the arse, but you can live with it. What the article is talking about is entirely different (see above).
Read the fucking article - you don't have to have any access to the victim site to do this - you only need to have a higher pagerank than them.
I can't foresee any occasion where I'd accept DRM, ever. Allow me to explain:
DRM only works if it's supported right down to the hardware, and I fundamentally object to my computer having a different agenda to mine. I will not buy hardware that I'm not in control of, and I view it as irresponsible and invasive to even try to control or artificially limit something I've paid (my) good money for.
If you don't understand this attitude, ask yourself why the government fines people for speeding but doesn't install mandatory speed-limiters in cars, or makes murder illegal but doesn't ban guns outright. Precedents both.
DRM without end-to-end hardware support is essentially impotent unless you are prohibited from cracking it by law. Legislating against technology like this is like legislating against bad weather, or against the tide - it's coming eventually whether you like it or not, and you only look stupid and/or put yourself in harm's way by trying to get between it and where it's going.
(As an aside, can anyone think of an example where a popular technology has been legislated against, and it's died there and then? I honestly can't think of one. In contrast, I can think of several cases where legal proceedings (and the attendant publicity) have launched a new piece of techology into mainstream usage, but I can't think of one counterexample. If anyone else can, please let me know...)
Short version - end-to-end DRM is fundamentally invasive and tramples on your rights as a consumer (First Sale, Fair Use, etc). Vulnerable DRM propped up by dubious lawmaking both cheapens the law and retards technology as a whole (e.g. banning P2P networks unless they pro-actively filter for copyrighted software effectively bands P2P as a useful technology).
DRM represents an attempt to graft concepts and precedent from physical property law onto digital "property". They are not alike, and this sets a false precedent which will (and is) harming both our technological and cultural development.
Yeah, I saw the article, but didn't read up on the in-depth details of how it worked at the time. Anyway...
.jar's contents available and crack any encryption or it'd be essentially worthless.
1) The Java Community provide an OS dependent security call for the JVM to make that would make contents available to any available AV software for inspection.
This still doesn't solve the problem of encryption (even something as simple as XORing). The problem is recognising native executable code as different from JVM bytecode, when all you're looking at is essentially a string of (optionally encrypted) characters. IIRC, you'd have to make the
2) Monitor calls that create or rename system files. This would be monitoring data flowing through JNI, and would be monitoring for and either disallow or request permission with specific file names OS dependent commands to create or rename files to executable extensions. This is native direct OS API stuff, not trying to determine what any program called might do.
Granted, this has a chance of working, but it would be a bit of a nightmare to keep the list of "executable files" up-to-date - straight off the top of my head I can think of exe, com, bat, vbs, js, wsh, pif, cmd and lnk files - any of which can be used to create or somehow launch executable code (and microsoft do seem to like frequently creating new executable types).
Assuming the list is kept up-to-date asking the user before creating or opening any of these filetypes would work, but you'd have to be careful to make the user understand what was happening, and we'd essentially end up with the same problem as before - user blithely clicks "yes" and the whole thing unravels...
The major problem is the naive user is in the loop. The "Firefox exploit" (sic) worked because the user didn't know any better than to click "yes, I trust this company" - replacing this simple question with a slightly more complex one ("yes, I trust this company to download/open/rename this file to that filename") doesn't stop the problem. If anything it only make it worse (since in my experience if a user doesn't understand a question they tend to just hit "yes").
Basically, to avoid naive user attacks you need to
1) Educate the user (not likely, at least in the short term - classic users are lazy and stupid), or
2) Take the naive user out of the loop - have some automatic way of detecting and preventing the exploit, so a naive user can't drop their spyware defences.
You can't fix a social exploit without educating the user or taking him out of the loop...
'Say you get in a car accident and you've been smoking pot... You're only going four miles an hour!
EEEEEEEEEEeeeeehhr. BOOM.
"Shit... we hit something."
"Forgot to open the garage door, man."
"We've gotta get the garage door open so Dominos knows we're home!"'
Classic.