Ok, so, add to that, two books on how to murder someone to get away with it, your wife has dissappeared after a bitter divorce when she banged your best friend while you were getting blown by little sventis in Russia, that, he goes and tries and hides this car 3 miles away from where he lived... and it wasn't even his car.
See, with that much, we could have an intelligent discussion. I still think it's not enough. See other comments, by other people -- how the best friend claimed to be a serial killer, how he was into BDSM... How other pieces don't add up; if she's a doctor, what's she doing as a translator?
However, what you had before was nowhere near enough to sentence him to even a slap on the wrist.
by some absolute consideration, unless they had a witness of him actually killing her, then yeah, there's some doubt, but its not reasonable doubt.
Strawman. There is real evidence -- like, say, a body, or a trail of blood leading to an incinerator -- and then there is wholly circumstantial evidence, like that his car was wet, he liked to read about murder, and he was living out of his car -- not wholly surprising, considering how much Namesys was not making money at the time.
there is evolution, there is global warming
These are scientific theories, backed by repeatable experiments. The same cannot be said of a wet car and reading habits.
Reiser was a very controlling husband who dominated his wife.
He trashed her career so he could work on his, would disappear for months at a time in Russia, and then, by other witnesses, often screamed at her over the phone.
remove the passenger seat.
$9000 in cash
That is the evidence. Now, here is where your speculation starts -- and by "speculation", I mean "making shit up":
I've had to live in my car, but I've never been in a situation where I felt like I needed to remove the passenger seat.
I've never had to live in my car, so you must never have had to, either, right?
Just because you never had to remove the passenger seat doesn't mean it's impossible for anyone to, or that the only reason you could possibly ever have is to clean blood from it.
Even in the USA, Reiser could have rented a room for like $200-$300 a month, an apartment for $500-$600
So what?
There are any number of reasons you might be living in your car. Money is only one, perhaps the only you can think of. Or perhaps he needed the money for something else.
the most convenient way to put money in the hands of a Russian programmer is electronically.
The most convenient way to put money in anyone's hands is electronically, yet US people write checks all the time. Why should Russian programmers be any different?
And now we move to the exercise in creative writing...
Reiser killed Nina in the car, and cleaned it out thoroughly, which explains why it was wet, except for the seat she was sitting in, which had to be removed. The seat is probably with the body, most likely. The $9000 in cash and passport were to allow him to leave the country and go to Russia, and the reason he ran from the cops, to begin with, is that he knew that he did it.
And you just made all of that up.
Go look up the definition for "reasonable doubt". We send people away when there is no other reasonable explanation for the evidence.
Well, fuck you. I've had a wet car, I've removed the seat from a car, I've had friends run from the cops (stupid thing to do, but still, doesn't make them guilty), and I have carried more cash than I should. And I've never killed anyone.
Maybe he did kill her, but nobody knows. Because nobody knows, and because we're in America, he should walk.
Unfortunately, because we're in America, you also have committed no crime by being an ignorant hate-spewing fucktard.
the point is that HTML already uses indenting to some degree
No, it doesn't.
Some HTML authors, maybe. HTML itself, no.
and has rules that make sequential whitespace unimportant in most cases combined with stylistic constraints like not line breaking inside attributes.
So?
embedding a langauge where whitespace is significant inside a markup where whitespace is insignificant is retarded.
Which is why I didn't suggest that, moron.
I suggested embedding it in the web browser. No one in their right mind writes a serious web app entirely inside <script> tags. You write it in an external.js file, and use the src attribute to refer to it.
what happens when you want to invoke python inline in an onclick for example, and need to start a new line?
You don't. You put the script somewhere else, and invoke it from an onclick. Allowing inline script there was about as stupid a move as allowing the <FONT> tag to exist.
you cant use the HTML's level of indenting because python needs its own, so what do you do?
Been awhile since I worked with Python, but if I understand it, Python only requires the indentation to be constant within a scope. Thus -- again, guessing here -- but I would imagine that simply breaking in the first place, then adding as much indentation as you want, would work fine. That goes for the script tag, too, assuming you're that stupid.
what about when a script tag starts at a certain level of indentation?
Then you add a src="myscript.py" attribute to your script tag, and add a closing script tag.
basically you're a moron.
Well, I am kind of abstractly maybe suggesting replacing Javascript with Python, so maybe.
But you're the one choosing a language based on purely syntactical reasons, especially when they're so trivially solved. There are so much better reasons not to jump to Python yet. Like the GIL...
And that is why I really, really want the patent issue to go away. It really depends how Microsoft uses those patents.
If they are actually about making a new open standard, and not locking Linux out once and for all, they may eventually give up control of those patents.
In the meantime... Silverlight, if I understand it, can actually do hardware-accelerated vector graphics and animations, controlled from "script". And the "script" is a bytecode language, thus you can have closed code if you want it, or open code in any language that can compile to it, not just Javascript. And, hell, Silverlight can probably do threading, too! (Something even ES4 doesn't seem likely to fix.)
But this just brings to mind... What we really need is PNG.
See, if you remember, back in the day, there was GIF and JPEG. The problem was, GIF was patent-encumbered, and thus, GNU, in particular, refused to implement it, and others did implement it, at their own risk. There was much furor over it -- campaigns against GIF, threats to sue people writing GIF software without paying a $5k fee (at least) for the patent...
Two things happened.
First, the free software community invented PNG, which is like GIF, but better in absolutely every way, except that old versions of IE didn't support it without a plugin, and new versions still don't support it as well as Firefox. Basically, PNGs use a different but better compression algorithm, support all the features GIFs do and more, and are pretty much the only image format you will ever need for lossless images. (If your image is really that big, use Jpeg.)
Second, the GIF patent (actually a patent on the compression involved) expired, way back in 2003. So, we can now use GIFs if we really want to, even though they've been completely obsoleted by PNGs. There's now no legal or convenience reason not to use GIFs, only the technological reasons -- and on technological merits alone, GIF loses. Hell, I do HD-DVD development, which is kind of Microsoft's baby, right? We use PNG images pretty much exclusively. I think the spec might support JPEG, but I doubt it supports GIF.
So, if mono is really doomed to patent bullshit, we need to pull that off again -- invent something like PNG, get it supported in Firefox. I'm not sure we can do it this time, though.
But sorry, (X)HTML5/CSS3/ES4 is not that. In part, it's not that precisely because web standards people don't take your attitude -- each of those components try to be as backwards-compatible as they reasonably can.
Looks like the way it works is, a few things that were obviously broken in Javascript are finally getting fixed. This will break code that relies on the old (broken) behavior, but it should be possible to write code that works on both. (If this is what I think it is, it can be solved with a search and replace.)
And it looks like Microsoft is arguing for what I suggested, while Mozilla (and others) are arguing that any <script> tag should run the new version.
As for "just don't break anything", I think it's worth it, really. Frankly, again, assuming the features are what I think they are (and I don't seem to be batting 100% right now), it's kind of like all that code for x86 which assumed that certain things were 32 bits, or that you could always use an int as a pointer, etc. Notice, also, how there's tons of code that just compiles and runs fine on x86_64, with zero effort on the part of the developer, and really no thought put into supporting it -- they simply used best practices.
As I understand it, the basic way this will work is, if there's no version number requested by the script, some heuristic will be used, in such a way that pretty much any script will end up being run the old way.
The new way would be to specify a version. For example:
<script version="4.0">
This both solves your problem, and makes the Microsoft argument irrelevant. Ok, yes, IE will have to throw resources at it -- boo frickin' hoo, you're Microsoft. Don't you have Developers? Developers? Developers? Developers?
But for the existing Web, everything will continue to work on new browsers. All we'll see is that some new websites will only work on the new browsers, and not on the existing ones. Which is fine, really, as most people are getting auto-updated to the latest browser as a matter of course.
By the time that a good chunk of all browsers actually support ECMA 4, it's going to be a "nice to have" feature that nobody's going to be too keen on.
...compiler where you could add whatever local features you need and have the compiler throw away the fluff and stick in cross-browser compatible shims.
Even without eval, Javascript alone is sufficient to do this in, provided you start with something that's sufficiently like Javascript.
Maybe you can't change syntax, but with ECMAScript 3 today, you absolutely can muck about with just about anything that's browser-specific, be it in the API itself or in your own (already written) functions or classes -- that's what's cool about a dynamic, prototype-based language -- until you basically have a cross-platform library with all the platform-specific crud in there, and your actual Javascript, while it's executed "natively", is also fairly lightweight, platform-agnostic stuff.
I think a similar solution could work via JavaScript: instead of sending it off to the server, allow a script to be executed asynchronously. It would have no access to any information not sent to it when it was started (as otherwise the thread synchronization issues would remain), but it could run a task and then return a result.
That would make Javascript a lot less usable.
I really see only one way that this could work well, and that is to not allow complex structures to be passed in -- to basically turn it into multiprocessing, the way it's done on Unix, with pipes. This is workable, but also inefficient and frustrating.
Then again, you're kind of already doing the serialization to talk to a web service... But still. There has got to be a better solution.
As for why I consider this unusable, just look at some of the better event handling code. Passing a closure to be executed asynchronously is a really cool design pattern, that I really would not want to lose.
Even if it helps MS, I want Javascript to die, die, die.
You (and others) keep saying this, but with nothing to back it up. You just take it on faith that everyone else agrees with you.
I think Javascript is a beautiful language. And I've worked with Ruby, Perl, Python, etc. There are about two or three things that I hate about Javascript, and all of them can be worked around with relative ease.
The downside of Silverlight is the possibility of patent issues. If that ever goes away, and particularly, if Silverlight ever gets vetted by a standard body, it looks good.
Here's why:
You want the old Javascript? Fine. You want the new, Mozilla-sponsored, v4 or whatever of ECMAScript? Fine. You want Python, Ruby, or Java? Go right ahead.
A bytecode engine in the browser is both long overdue, and this is why. This way, no one gets to bitch about the language in the browser (though I like Javascript just fine for most purposes), as you can run just about any language there.
(Ok, Java did a bytecode engine in the browser, but Java applets sucked. I think Silverlight has the potential to suck a lot less than Java did.)
Both can be wrapped in libraries. And this has been done.
Trust me on this -- I do HDi (HD-DVD) development. There are fairly big differences between Javascript on HDi and Javascript in a Web browser -- but there are actually a lot of library functions we can port over from the Web, and very little we have to do from one HDi implementation to another. You mentioned Microsoft's Javascript implementation -- actually, that's JScript, so called because they are legally not allowed to call it JavaScript -- but JScript powers some HDi implementations, and completely different scripting engines power others.
I'd say, yes, screw two languages -- but not for the reasons you said. Screw two languages because porting between entirely different languages -- for instance, Perl to Ruby -- can be MUCH more work than porting between Javascript and ECMAScript, or between ECMAScript and HDi, or...
First prove that the whitespace is a bad idea. You're going to indent like that anyway, isn't it simpler just to...
No, nevermind.
First, prove that this flamewar about whitespace has anything at all to do with the requirements that it be a script, that it be client-side, or that it be in a web browser. For that reason alone, this should be -1 Offtopic.
I can think of a few valid reasons why Python wouldn't work well for this, at least without some serious hacking. Whitespace isn't one of them.
(And if it was, like I keep telling people -- write a preprocessor, if syntax is all that keeps you from liking a language.)
I first heard about this yesterday, and went "Oh cool, so Google's finally implementing OpenID. Maybe they'll do for that what they did for Jabber."
You see, Google Talk is a Jabber IM service. That means that while the Google Talk client itself probably only works with Google, you can, in fact, talk to anyone, on any domain, on any Jabber server, from your Google Talk account, and vice versa. It's IM, but with the decentralization, flexibility, and possibility of competition that you find in email.
Well, OpenID is like that, but for authentication and profiles. I can sign up for an OpenID anywhere, and it will work anywhere that supports OpenID. It means that any site that would otherwise require free registration can simply require an OpenID. It's like single sign on, but your authentication server can be anywhere, and can be tied to an account... and you can use any authentication method, really. Most people would use usernames/passwords, I'd probably use a PGP key or something.
Anyway...
It's not OpenID.
That's fine, the OpenID "standards" are a mess, but...
It's not even a replacement for OpenID. If anything, it's a replacement for Passport, but you have a Google account instead of an MSN account. Ok, yes, I can access my social networking data from any random website, as part of a web app -- but what if I don't want to be on Orkut?
In other words...
Why have they replaced a few tiny walled gardens (MySpace, Facebook) with a gated community? Why not just open it up, especially if you're going to pretend it's "open"?
I'd rather a competitor was born, but frankly, for many of these people? Not gonna happen. A Mac, even with Windows under Parallels, would become a requirement for professional graphics work.
Well, there's no redundancy between PC and console for a start.
While one of our more interesting new business models depends on people thinking this way, that's simply a choice you (and game developers) have made.
I don't want to sit on the sofa with a keyboard accross my knees for 4 hours playing Tabula Rasa.
Xbox controllers can plug into a computer, with an adapter. I believe 360 controllers can use USB cables. I imagine PS3 controllers can pretty easily now, too -- I know those are USB.
In other words, you're making a (wrong, stupid) assumption that a keyboard is the only interface to a computer. The only reason this assumption has any validity is because everyone agrees on it -- an "emperor's new clothes" situation. Many PC games support a joystick, and you can buy many controllers to plug into a PC, and you can buy PCs (or video cards) with TV out (even HDMI)...
Likewise I don't want to try and get 4 people round a 19" monitor to play Wii.
Now I know you haven't thought this through.
At work, I recently got a TV for my desk. It has an HDMI port on the back (for which you can get a DVI->HDMI adapter), as well as straight VGA. Basically, with no fuss at all, you can plug a computer into it. Most new TVs will be the same.
Similarly, at home, my monitor has component video inputs. I could, in fact, plug a Wii into my 20" monitor if I really wanted to.
The only difference between a TV and a monitor anymore is that TVs can get away with overscan, which is cheap-ass bullshit to begin with.
Now, I can see there being redundancy if we're talking about more than one person -- for example, I could use the PC while you use the console. So there is some value to having a collection of consoles -- but why must they all be different, mutually-incompatible consoles (and computers)?
In other words, why can't you have the computer at a desk, one computer at each TV, etc? That way, you don't have the issue of everyone wanting to play the same game, or even two different games that you only have for one console. (If you say "but they could take turns", you've negated the advantage of having multiple consoles. If you say "but they could play a different game", that's yet another artificial inconvenience.)
As another poster said in this article, "You don't buy a Ferrari and then complain about the gas mileage".
They obviously don't know any rich assholes who own Ferraris.
Anyone who will have the cash to shell out for one of these suckers is not going to give a crap about the electricity bill at the end of the month.
Wasteful idiots, then. Yes, I would care about the electricity bill, for precisely the reason I outlined...
In fact, they probably want to exploit the power of their new computational Ferrari.
Presumably, if they bought this, they actually have some use for it.
As such, I think it is very reasonable to use its power for the good of mankind. Mind you, your donation is not (yet) tax deductible.
Which is why I think it would be more reasonable to simply donate money to a project which buys PS3s and turns them into nodes for a project like this.
Lastly, you are a little outdated in your knowledge. World Community Grid has BOINC settings that allow you to throttle the usage as far down as you like.
Irrelevant. I know how to throttle individual apps if I have to, whether they have such settings or not.
Furthermore, it defaults to OFF when on battery.
So then, if I have my laptop in my lap, but plugged in? Ouch.
So, while you yourself may be so fiscally constrained that you cannot afford the electricity
It's not about being fiscally constrained. It's about not being fiscally stupid.
Now, maybe you have run the numbers, and decided that this is a lot more efficient use of your money to help these projects. If so, good for you, and I'd again suggest it really only makes sense on a desktop, or (especially) a server. (I mentioned EC2 as a possibility -- Amazon won't charge you more money if you bump their electric bill that way.)
I wholeheartedly disagree. Portal was all about the story. Without the story and the character dev between the player-character and the GladOS, it would just be a puzzle/maze game.
And as a puzzle/maze game, it would still have been one of the most original and interesting ones I've played in awhile, and well worth the $20.
Don't get me wrong, I loved the story. I would have bought it just for the story, even if it was just another shooter. It would still have been unique, cute, deep (sort-of), hilarious, and generally worth playing.
More to topic, though - I agree that shorter, episodic content is the way to go now.
I wouldn't necessarily say that. There have been some very good, very long games. And there are short, episodic games which form a series, such that you really should play the whole series all the way through.
I do think that shorter, episodic content has a place, but really, what makes a game for me is... wait for it... Good content, good gameplay, a solid engine (good graphics don't hurt), and a good story. Making a game episodic won't automatically give you that, nor will making a huge, $50-60 game destroy that. Sports games don't automatically have to have no story, any more than RPGs have to have one (see Warcraft -- the story is there, but everyone ignores it).
Only point I was making was that good, episodic, stand-alone content has been done, and in the right price range. (Original post was someone complaining that it wasn't being done at all.)
While that is kind of a bastard move for Microsoft to do (and probably part of the reason Napster is getting out), it still doesn't change the viability of the subscription model. See, if you have, say, a Rio or something (not really sure what is PlaysForSure compatible), you subscribe to one store. If it dies and you buy a Zune (or vice versa), you simply switch to the Zune store (or to another one).
Compare that to iTunes -- if you "buy" a (DRM'd) song, there's no lossless way of making it work on another player, even if there were many players supporting unencrypted AAC.
This seems to be what their defense would be, to unlock the content you have to break the law, via DMCA, ergo it is not our(Rockstar's) fault.
That absolutely should work. Pick one or the other -- either it's illegal to do this, and thus not Rockstar's fault, or it's legal to do this, and thus Ubuntu can include libdvdcss.
Where does the line of responsibility end? Why do the content producers have to be responsible for everything the users do?
Because OH NOES THINK OF THE CHILDREN!
Really, at least the content was here, this time. Compare it to, say, the Oblivion re-rating, where a completely third-party mod -- not an "unlocking", but an actual downloading of new content -- included nudity. (Think it was only breasts, anyway. OH THE HUMANITY.) Roughly equivalent to Firefox getting an NC-17 rating because you COULD be looking at goat porn.
But hey, in an era where the PSP gets nicknamed the "Playstation Pornable" by the press simply because it includes a web browser and wireless access...
If I feel strongly enough about an issue, I might write a Slashdot post. If I'm moderate, I probably don't have much to say, and thus, I won't bother to write a post.
I imagine the reason you see Slashdot (and many other sites) as a perpetual flamewar is that the majority, who aren't flaming, simply aren't interested enough to post -- maybe not even interested enough to click the article, so they move on to flame about something they do care about.
They say you spend the first couple years of your life learning how to talk, and the rest of it learning how to shut up.
As in, I'm one of the few people for which this would be a bad idea, as I basically refuse to buy DRM'd media for my own use. Partly on principle, mostly because it won't work on Linux.
But for most people, if you actually calculate it out, the DRM is the only bad part. It's otherwise a damned good model -- as others have pointed out, it costs about the same as satellite radio, but you get to pick what you want to listen to, and you can throw it all on a Zune (or any PlaysForSure player) and take it wherever you want, play it in whatever order you want, etc. At least a few people who use this have calculated for me how much each track/album they've downloaded would cost on iTunes or CD, and then how long they'd have to stay subscribed for the subscription to start to be a bad deal.
It was 15 years.
And I really don't think I will be listening to the same music in another 15 years. Some of it, yes, but I'll certainly be listening to other, yet-to-be-released music.
"But what if the service goes away???"
A legitimate complaint for something like Steam, where if the service goes away, you can't play Half-Life 2. There's really no alternative to that. But most of the music that's available on one service would be available on another, so they're basically a commodity. And Internet is fast enough that having to re-download them is entirely not an issue, assuming the interface is made slick enough. (Have it pretend they're already on my hard drive, so I can throw them in a playlist, then download them on demand.)
So yeah, the only reason I buy music by the song/album, and listen to internet radio, is because that all works on Linux, and generally isn't DRM'd, and I have the option of putting it on non-PlaysForMaybe players -- like, oh, an iPod. (Or an iPhone, or an Archos with Rockbox, or the Ubuntu machines down at our local radio station...)
A gigabyte here, a gigabyte there, pretty soon we're going to be talking about some actual wasted disk space...
The higher you get, the more the difference will be.
1 kilobyte, as labeled by Seagate (and every other storage manufacturer), is actually 0.98 kilobytes -- big deal, you lose 24 bytes.
1 megabyte is actually 0.95 megabytes, or 976 kilobytes, so you lose 47 kilobytes.
1 gigabyte is actually 0.93 gigabytes, or 953 megabytes, so you lose 70 megabytes.
1 terabyte is actually 0.90 terabytes, or 931 gigabytes, so you lose 92 gigabytes.
I don't know about you, but even with a terabyte of space, 92 gigabytes hardly seems insignificant. And at a petabyte, it becomes 115 terabytes. And so on.
Sure, you can have a 1-byte file, but it'll use up 512 bytes or more space on the HD... So, which is it? Is it a 1-byte file, or really a 512-byte (or 1024 or 2048 or 4096 or...) file?
First off, modern OSes generally do have a way of telling you both values -- both how big a file logically is, and how much space it uses on-disk.
Second, both ReiserFS and Reiser4 -- and pretty much no other FS, sadly -- do a form of "tail packing". Essentially, if the last block of a file doesn't use the whole block, they pack it somewhere -- in ReiserFS, they pack it right into the directory structure. In Reiser4, they use something akin to extent lists to pack the files as tightly as possible, separate from the metadata (directory structure), though.
I believe this does tend to fragment things more, but if you want to use all that space, you can. In Reiser4, it gets even better -- you could have transparent, read/write compression on top of that, with no loss of performance. (I've read the whitepaper; it would work, but it's also not trivial.)
And there's a really good reason for using such a filesystem: Mailservers. Webservers are getting less relevant, as they can pretty much store everything in a database, which will throw all the data for all the pages into only a few physical files on-disk, as seen by the filesystem. However, at least a few UNIX-based mailservers do what I consider the "right thing" -- they store the mail in Maildir format, which makes it very interoperable, and ludicrously easy to script for. It also performs well -- better than mbox, the only other standard format for an on-disk representation of a mailbox -- mbox uses single files, basically all your mail concatenated together with special characters marking the beginning of a new message. So yeah, mbox sucks, maildir rules, except maildir means you'll be dealing with many hundreds of thousands of files. Could be as much as 2-3 times smaller on a Reiser-based (or similar) filesystem.
That's 2-3 times over pretty much the entire mail spool and folders (if you're doing IMAP). That means, if you were running a mailserver (I'm assuming you're not), simply switching filesystems could mean the difference between a 500 gig hard drive and a 1 terabyte array.
Or, if you want a solution right now for the more archived files, just pack the files in an archive of some sort --.tar.bz2 for long-term storage, or something like zip for quick access. There are FUSE drivers to actually be able to mount these -- or you can use things like cramfs, squashfs, etc.
Finally, a real-life example from work: Sure, all our source files for HD-DVD development are stored individually on NTFS, FAT32, ext3, etc. But most of the interactive content (scripts, XML, PNG images) gets thrown into an aca file on-disk. This isn't for storage purposes, actually, but performance -- the HD-DVD player can, presumably, just slurp the whole aca into RAM and run it from there, and it can do it as a sequential read (no seeks).
Even if you don't want that extra space, may as well use it for something, right? Maybe some parity bits?
Well, that was quite a lot of work put into proving you wrong. Hope it was educational, at least...
Slashdot Mirror
See, with that much, we could have an intelligent discussion. I still think it's not enough. See other comments, by other people -- how the best friend claimed to be a serial killer, how he was into BDSM... How other pieces don't add up; if she's a doctor, what's she doing as a translator?
However, what you had before was nowhere near enough to sentence him to even a slap on the wrist.
Strawman. There is real evidence -- like, say, a body, or a trail of blood leading to an incinerator -- and then there is wholly circumstantial evidence, like that his car was wet, he liked to read about murder, and he was living out of his car -- not wholly surprising, considering how much Namesys was not making money at the time.
These are scientific theories, backed by repeatable experiments. The same cannot be said of a wet car and reading habits.
Let me assemble your "evidence" here:
That is the evidence. Now, here is where your speculation starts -- and by "speculation", I mean "making shit up":
I've never had to live in my car, so you must never have had to, either, right?
Just because you never had to remove the passenger seat doesn't mean it's impossible for anyone to, or that the only reason you could possibly ever have is to clean blood from it.
So what?
There are any number of reasons you might be living in your car. Money is only one, perhaps the only you can think of. Or perhaps he needed the money for something else.
The most convenient way to put money in anyone's hands is electronically, yet US people write checks all the time. Why should Russian programmers be any different?
And now we move to the exercise in creative writing...
And you just made all of that up.
Go look up the definition for "reasonable doubt". We send people away when there is no other reasonable explanation for the evidence.
Well, fuck you. I've had a wet car, I've removed the seat from a car, I've had friends run from the cops (stupid thing to do, but still, doesn't make them guilty), and I have carried more cash than I should. And I've never killed anyone.
Maybe he did kill her, but nobody knows. Because nobody knows, and because we're in America, he should walk.
Unfortunately, because we're in America, you also have committed no crime by being an ignorant hate-spewing fucktard.
No, it doesn't.
Some HTML authors, maybe. HTML itself, no.
So?
Which is why I didn't suggest that, moron.
I suggested embedding it in the web browser. No one in their right mind writes a serious web app entirely inside <script> tags. You write it in an external .js file, and use the src attribute to refer to it.
You don't. You put the script somewhere else, and invoke it from an onclick. Allowing inline script there was about as stupid a move as allowing the <FONT> tag to exist.
Been awhile since I worked with Python, but if I understand it, Python only requires the indentation to be constant within a scope. Thus -- again, guessing here -- but I would imagine that simply breaking in the first place, then adding as much indentation as you want, would work fine. That goes for the script tag, too, assuming you're that stupid.
Then you add a src="myscript.py" attribute to your script tag, and add a closing script tag.
Well, I am kind of abstractly maybe suggesting replacing Javascript with Python, so maybe.
But you're the one choosing a language based on purely syntactical reasons, especially when they're so trivially solved. There are so much better reasons not to jump to Python yet. Like the GIL...
And that is why I really, really want the patent issue to go away. It really depends how Microsoft uses those patents.
If they are actually about making a new open standard, and not locking Linux out once and for all, they may eventually give up control of those patents.
In the meantime... Silverlight, if I understand it, can actually do hardware-accelerated vector graphics and animations, controlled from "script". And the "script" is a bytecode language, thus you can have closed code if you want it, or open code in any language that can compile to it, not just Javascript. And, hell, Silverlight can probably do threading, too! (Something even ES4 doesn't seem likely to fix.)
But this just brings to mind... What we really need is PNG.
See, if you remember, back in the day, there was GIF and JPEG. The problem was, GIF was patent-encumbered, and thus, GNU, in particular, refused to implement it, and others did implement it, at their own risk. There was much furor over it -- campaigns against GIF, threats to sue people writing GIF software without paying a $5k fee (at least) for the patent...
Two things happened.
First, the free software community invented PNG, which is like GIF, but better in absolutely every way, except that old versions of IE didn't support it without a plugin, and new versions still don't support it as well as Firefox. Basically, PNGs use a different but better compression algorithm, support all the features GIFs do and more, and are pretty much the only image format you will ever need for lossless images. (If your image is really that big, use Jpeg.)
Second, the GIF patent (actually a patent on the compression involved) expired, way back in 2003. So, we can now use GIFs if we really want to, even though they've been completely obsoleted by PNGs. There's now no legal or convenience reason not to use GIFs, only the technological reasons -- and on technological merits alone, GIF loses. Hell, I do HD-DVD development, which is kind of Microsoft's baby, right? We use PNG images pretty much exclusively. I think the spec might support JPEG, but I doubt it supports GIF.
So, if mono is really doomed to patent bullshit, we need to pull that off again -- invent something like PNG, get it supported in Firefox. I'm not sure we can do it this time, though.
But sorry, (X)HTML5/CSS3/ES4 is not that. In part, it's not that precisely because web standards people don't take your attitude -- each of those components try to be as backwards-compatible as they reasonably can.
Wow. Sorry about that. Mod me down, hard, please.
Looks like the way it works is, a few things that were obviously broken in Javascript are finally getting fixed. This will break code that relies on the old (broken) behavior, but it should be possible to write code that works on both. (If this is what I think it is, it can be solved with a search and replace.)
And it looks like Microsoft is arguing for what I suggested, while Mozilla (and others) are arguing that any <script> tag should run the new version.
As for "just don't break anything", I think it's worth it, really. Frankly, again, assuming the features are what I think they are (and I don't seem to be batting 100% right now), it's kind of like all that code for x86 which assumed that certain things were 32 bits, or that you could always use an int as a pointer, etc. Notice, also, how there's tons of code that just compiles and runs fine on x86_64, with zero effort on the part of the developer, and really no thought put into supporting it -- they simply used best practices.
As I understand it, the basic way this will work is, if there's no version number requested by the script, some heuristic will be used, in such a way that pretty much any script will end up being run the old way.
The new way would be to specify a version. For example:
<script version="4.0">
This both solves your problem, and makes the Microsoft argument irrelevant. Ok, yes, IE will have to throw resources at it -- boo frickin' hoo, you're Microsoft. Don't you have Developers? Developers? Developers? Developers?
But for the existing Web, everything will continue to work on new browsers. All we'll see is that some new websites will only work on the new browsers, and not on the existing ones. Which is fine, really, as most people are getting auto-updated to the latest browser as a matter of course.
Why?
Even without eval, Javascript alone is sufficient to do this in, provided you start with something that's sufficiently like Javascript.
Maybe you can't change syntax, but with ECMAScript 3 today, you absolutely can muck about with just about anything that's browser-specific, be it in the API itself or in your own (already written) functions or classes -- that's what's cool about a dynamic, prototype-based language -- until you basically have a cross-platform library with all the platform-specific crud in there, and your actual Javascript, while it's executed "natively", is also fairly lightweight, platform-agnostic stuff.
That would make Javascript a lot less usable.
I really see only one way that this could work well, and that is to not allow complex structures to be passed in -- to basically turn it into multiprocessing, the way it's done on Unix, with pipes. This is workable, but also inefficient and frustrating.
Then again, you're kind of already doing the serialization to talk to a web service... But still. There has got to be a better solution.
As for why I consider this unusable, just look at some of the better event handling code. Passing a closure to be executed asynchronously is a really cool design pattern, that I really would not want to lose.
You (and others) keep saying this, but with nothing to back it up. You just take it on faith that everyone else agrees with you.
I think Javascript is a beautiful language. And I've worked with Ruby, Perl, Python, etc. There are about two or three things that I hate about Javascript, and all of them can be worked around with relative ease.
The downside of Silverlight is the possibility of patent issues. If that ever goes away, and particularly, if Silverlight ever gets vetted by a standard body, it looks good.
Here's why:
You want the old Javascript? Fine.
You want the new, Mozilla-sponsored, v4 or whatever of ECMAScript? Fine.
You want Python, Ruby, or Java? Go right ahead.
A bytecode engine in the browser is both long overdue, and this is why. This way, no one gets to bitch about the language in the browser (though I like Javascript just fine for most purposes), as you can run just about any language there.
(Ok, Java did a bytecode engine in the browser, but Java applets sucked. I think Silverlight has the potential to suck a lot less than Java did.)
Both can be wrapped in libraries. And this has been done.
Trust me on this -- I do HDi (HD-DVD) development. There are fairly big differences between Javascript on HDi and Javascript in a Web browser -- but there are actually a lot of library functions we can port over from the Web, and very little we have to do from one HDi implementation to another. You mentioned Microsoft's Javascript implementation -- actually, that's JScript, so called because they are legally not allowed to call it JavaScript -- but JScript powers some HDi implementations, and completely different scripting engines power others.
I'd say, yes, screw two languages -- but not for the reasons you said. Screw two languages because porting between entirely different languages -- for instance, Perl to Ruby -- can be MUCH more work than porting between Javascript and ECMAScript, or between ECMAScript and HDi, or...
First prove that the whitespace is a bad idea. You're going to indent like that anyway, isn't it simpler just to...
No, nevermind.
First, prove that this flamewar about whitespace has anything at all to do with the requirements that it be a script, that it be client-side, or that it be in a web browser. For that reason alone, this should be -1 Offtopic.
I can think of a few valid reasons why Python wouldn't work well for this, at least without some serious hacking. Whitespace isn't one of them.
(And if it was, like I keep telling people -- write a preprocessor, if syntax is all that keeps you from liking a language.)
Go read some Douglas Crockford.
Javascript is about as powerful as Lisp or Ruby, and certainly no less powerful than Python.
If it's the syntax that's bugging you, write a preprocessor and shut up.
I first heard about this yesterday, and went "Oh cool, so Google's finally implementing OpenID. Maybe they'll do for that what they did for Jabber."
You see, Google Talk is a Jabber IM service. That means that while the Google Talk client itself probably only works with Google, you can, in fact, talk to anyone, on any domain, on any Jabber server, from your Google Talk account, and vice versa. It's IM, but with the decentralization, flexibility, and possibility of competition that you find in email.
Well, OpenID is like that, but for authentication and profiles. I can sign up for an OpenID anywhere, and it will work anywhere that supports OpenID. It means that any site that would otherwise require free registration can simply require an OpenID. It's like single sign on, but your authentication server can be anywhere, and can be tied to an account... and you can use any authentication method, really. Most people would use usernames/passwords, I'd probably use a PGP key or something.
Anyway...
It's not OpenID.
That's fine, the OpenID "standards" are a mess, but...
It's not even a replacement for OpenID. If anything, it's a replacement for Passport, but you have a Google account instead of an MSN account. Ok, yes, I can access my social networking data from any random website, as part of a web app -- but what if I don't want to be on Orkut?
In other words...
Why have they replaced a few tiny walled gardens (MySpace, Facebook) with a gated community? Why not just open it up, especially if you're going to pretend it's "open"?
...they don't just stay on the Macs.
I'd rather a competitor was born, but frankly, for many of these people? Not gonna happen. A Mac, even with Windows under Parallels, would become a requirement for professional graphics work.
While one of our more interesting new business models depends on people thinking this way, that's simply a choice you (and game developers) have made.
Xbox controllers can plug into a computer, with an adapter. I believe 360 controllers can use USB cables. I imagine PS3 controllers can pretty easily now, too -- I know those are USB.
In other words, you're making a (wrong, stupid) assumption that a keyboard is the only interface to a computer. The only reason this assumption has any validity is because everyone agrees on it -- an "emperor's new clothes" situation. Many PC games support a joystick, and you can buy many controllers to plug into a PC, and you can buy PCs (or video cards) with TV out (even HDMI)...
Now I know you haven't thought this through.
At work, I recently got a TV for my desk. It has an HDMI port on the back (for which you can get a DVI->HDMI adapter), as well as straight VGA. Basically, with no fuss at all, you can plug a computer into it. Most new TVs will be the same.
Similarly, at home, my monitor has component video inputs. I could, in fact, plug a Wii into my 20" monitor if I really wanted to.
The only difference between a TV and a monitor anymore is that TVs can get away with overscan, which is cheap-ass bullshit to begin with.
Now, I can see there being redundancy if we're talking about more than one person -- for example, I could use the PC while you use the console. So there is some value to having a collection of consoles -- but why must they all be different, mutually-incompatible consoles (and computers)?
In other words, why can't you have the computer at a desk, one computer at each TV, etc? That way, you don't have the issue of everyone wanting to play the same game, or even two different games that you only have for one console. (If you say "but they could take turns", you've negated the advantage of having multiple consoles. If you say "but they could play a different game", that's yet another artificial inconvenience.)
They obviously don't know any rich assholes who own Ferraris.
Wasteful idiots, then. Yes, I would care about the electricity bill, for precisely the reason I outlined...
Presumably, if they bought this, they actually have some use for it.
Which is why I think it would be more reasonable to simply donate money to a project which buys PS3s and turns them into nodes for a project like this.
Irrelevant. I know how to throttle individual apps if I have to, whether they have such settings or not.
So then, if I have my laptop in my lap, but plugged in? Ouch.
It's not about being fiscally constrained. It's about not being fiscally stupid.
Now, maybe you have run the numbers, and decided that this is a lot more efficient use of your money to help these projects. If so, good for you, and I'd again suggest it really only makes sense on a desktop, or (especially) a server. (I mentioned EC2 as a possibility -- Amazon won't charge you more money if you bump their electric bill that way.)
And as a puzzle/maze game, it would still have been one of the most original and interesting ones I've played in awhile, and well worth the $20.
Don't get me wrong, I loved the story. I would have bought it just for the story, even if it was just another shooter. It would still have been unique, cute, deep (sort-of), hilarious, and generally worth playing.
I wouldn't necessarily say that. There have been some very good, very long games. And there are short, episodic games which form a series, such that you really should play the whole series all the way through.
I do think that shorter, episodic content has a place, but really, what makes a game for me is... wait for it... Good content, good gameplay, a solid engine (good graphics don't hurt), and a good story. Making a game episodic won't automatically give you that, nor will making a huge, $50-60 game destroy that. Sports games don't automatically have to have no story, any more than RPGs have to have one (see Warcraft -- the story is there, but everyone ignores it).
Only point I was making was that good, episodic, stand-alone content has been done, and in the right price range. (Original post was someone complaining that it wasn't being done at all.)
Ah, I'd forgotten.
While that is kind of a bastard move for Microsoft to do (and probably part of the reason Napster is getting out), it still doesn't change the viability of the subscription model. See, if you have, say, a Rio or something (not really sure what is PlaysForSure compatible), you subscribe to one store. If it dies and you buy a Zune (or vice versa), you simply switch to the Zune store (or to another one).
Compare that to iTunes -- if you "buy" a (DRM'd) song, there's no lossless way of making it work on another player, even if there were many players supporting unencrypted AAC.
Hard to tell who copies who anymore, but it IS a nice feature on both systems. (Of course, on XBL, you'd have to find that game disc...)
That absolutely should work. Pick one or the other -- either it's illegal to do this, and thus not Rockstar's fault, or it's legal to do this, and thus Ubuntu can include libdvdcss.
Because OH NOES THINK OF THE CHILDREN!
Really, at least the content was here, this time. Compare it to, say, the Oblivion re-rating, where a completely third-party mod -- not an "unlocking", but an actual downloading of new content -- included nudity. (Think it was only breasts, anyway. OH THE HUMANITY.) Roughly equivalent to Firefox getting an NC-17 rating because you COULD be looking at goat porn.
But hey, in an era where the PSP gets nicknamed the "Playstation Pornable" by the press simply because it includes a web browser and wireless access...
I'll say no more. Or maybe... Yes! There's more!
This is basically what I do.
If I feel strongly enough about an issue, I might write a Slashdot post. If I'm moderate, I probably don't have much to say, and thus, I won't bother to write a post.
I imagine the reason you see Slashdot (and many other sites) as a perpetual flamewar is that the majority, who aren't flaming, simply aren't interested enough to post -- maybe not even interested enough to click the article, so they move on to flame about something they do care about.
They say you spend the first couple years of your life learning how to talk, and the rest of it learning how to shut up.
As in, I'm one of the few people for which this would be a bad idea, as I basically refuse to buy DRM'd media for my own use. Partly on principle, mostly because it won't work on Linux.
But for most people, if you actually calculate it out, the DRM is the only bad part. It's otherwise a damned good model -- as others have pointed out, it costs about the same as satellite radio, but you get to pick what you want to listen to, and you can throw it all on a Zune (or any PlaysForSure player) and take it wherever you want, play it in whatever order you want, etc. At least a few people who use this have calculated for me how much each track/album they've downloaded would cost on iTunes or CD, and then how long they'd have to stay subscribed for the subscription to start to be a bad deal.
It was 15 years.
And I really don't think I will be listening to the same music in another 15 years. Some of it, yes, but I'll certainly be listening to other, yet-to-be-released music.
"But what if the service goes away???"
A legitimate complaint for something like Steam, where if the service goes away, you can't play Half-Life 2. There's really no alternative to that. But most of the music that's available on one service would be available on another, so they're basically a commodity. And Internet is fast enough that having to re-download them is entirely not an issue, assuming the interface is made slick enough. (Have it pretend they're already on my hard drive, so I can throw them in a playlist, then download them on demand.)
So yeah, the only reason I buy music by the song/album, and listen to internet radio, is because that all works on Linux, and generally isn't DRM'd, and I have the option of putting it on non-PlaysForMaybe players -- like, oh, an iPod. (Or an iPhone, or an Archos with Rockbox, or the Ubuntu machines down at our local radio station...)
The higher you get, the more the difference will be.
1 kilobyte, as labeled by Seagate (and every other storage manufacturer), is actually 0.98 kilobytes -- big deal, you lose 24 bytes.
1 megabyte is actually 0.95 megabytes, or 976 kilobytes, so you lose 47 kilobytes.
1 gigabyte is actually 0.93 gigabytes, or 953 megabytes, so you lose 70 megabytes.
1 terabyte is actually 0.90 terabytes, or 931 gigabytes, so you lose 92 gigabytes.
I don't know about you, but even with a terabyte of space, 92 gigabytes hardly seems insignificant. And at a petabyte, it becomes 115 terabytes. And so on.
First off, modern OSes generally do have a way of telling you both values -- both how big a file logically is, and how much space it uses on-disk.
Second, both ReiserFS and Reiser4 -- and pretty much no other FS, sadly -- do a form of "tail packing". Essentially, if the last block of a file doesn't use the whole block, they pack it somewhere -- in ReiserFS, they pack it right into the directory structure. In Reiser4, they use something akin to extent lists to pack the files as tightly as possible, separate from the metadata (directory structure), though.
I believe this does tend to fragment things more, but if you want to use all that space, you can. In Reiser4, it gets even better -- you could have transparent, read/write compression on top of that, with no loss of performance. (I've read the whitepaper; it would work, but it's also not trivial.)
And there's a really good reason for using such a filesystem: Mailservers. Webservers are getting less relevant, as they can pretty much store everything in a database, which will throw all the data for all the pages into only a few physical files on-disk, as seen by the filesystem. However, at least a few UNIX-based mailservers do what I consider the "right thing" -- they store the mail in Maildir format, which makes it very interoperable, and ludicrously easy to script for. It also performs well -- better than mbox, the only other standard format for an on-disk representation of a mailbox -- mbox uses single files, basically all your mail concatenated together with special characters marking the beginning of a new message. So yeah, mbox sucks, maildir rules, except maildir means you'll be dealing with many hundreds of thousands of files. Could be as much as 2-3 times smaller on a Reiser-based (or similar) filesystem.
That's 2-3 times over pretty much the entire mail spool and folders (if you're doing IMAP). That means, if you were running a mailserver (I'm assuming you're not), simply switching filesystems could mean the difference between a 500 gig hard drive and a 1 terabyte array.
Or, if you want a solution right now for the more archived files, just pack the files in an archive of some sort -- .tar.bz2 for long-term storage, or something like zip for quick access. There are FUSE drivers to actually be able to mount these -- or you can use things like cramfs, squashfs, etc.
Finally, a real-life example from work: Sure, all our source files for HD-DVD development are stored individually on NTFS, FAT32, ext3, etc. But most of the interactive content (scripts, XML, PNG images) gets thrown into an aca file on-disk. This isn't for storage purposes, actually, but performance -- the HD-DVD player can, presumably, just slurp the whole aca into RAM and run it from there, and it can do it as a sequential read (no seeks).
Even if you don't want that extra space, may as well use it for something, right? Maybe some parity bits?
Well, that was quite a lot of work put into proving you wrong. Hope it was educational, at least...