I dunno, stuff like <verse>, <title>, and perhaps most useful, <author> - keep in mind we're talking about computerized semantics, not human readability.
The "semantic web" already runs mostly on magic - theoretically, people mark up sections of their document as having certain meanings (like an author) and then the "semantic browser" picks up on those. In this case, it might pick up on the author and allow searching for other stuff by the same author. Realistically, who is going to bother tagging their document by hand?
What's really more useful with XML and CSS is just making things clearer internally, so instead of doing something like <div class="title">, <div class="verse">, and so on, you'd just do <title>, <verse>, and so on. One of the main things CSS has done is made it so that more and more complicated webpages are becoming a mesh of <div>s and <span>s, making any semantic meaning that HTML has totally meaningless. (You gotta love <span class="bold"> over <b> as if that's somehow an improvement.)
Perhaps according to you, but not according to RFC 2854, which defines the text/html media type.
Actually, they say that the XHTML 1.0 mappings to "tag soup" can be marked as "text/html" but those markings are horrible anyway (and, best of all, invalid HTML 4.01). Calling XHTML "text/html" is still essentially broken. It's supposed to allow XHTML to be viewed with browsers that don't support XHTML, but it essentially removes the only advantage of XHTML - syntax checking.
It doesn't so long as it's a minority. When the overwhelming majority of the web uses XHTML, its draconian error handling that it inherits from XML will simplify browsers considerably.
It's always fun to take an "XHTML 1.0 site" and run it through an XML parser, see how far it gets before bombing. The "draconian error handling" essentially guarentees that it'll never take off, or even if it does, that most browsers will start allowing worse and worse XHTML.
That's completely wrong. Sure, you could make up your own semantics that you associate with the element types you use in your ad-hoc XML format, but nobody else would know about those semantics. That's why you use a common, specified XML format... like... XHTML
You do know that there are more XML schemas out there than just XHTML, right? There's no reason why you can't simply include xsi:schemaLocation and explain exactly what your XML contains. That's the entire point behind XML schemas. Theoretically, you can import various other schemas, so even if your site uses some custom XML markup, your schema can reference known other schemas and still make the data semantically meaningful.
However, suggesting that XHTML is magically more meaningful than a random XML document when it comes to semantics is just laughable. If you're trying to look at just the text, HTML offers various semantic meanings for the various tags. But if you want to go any further, like recognizing certain portions as addresses, XHTML offers no help. <div class="zipcode">1234</div> isn't any more semantically useful than <zipcode>1234</zipcode> - both require you to know the design of the specific document to be helpful.
Yeah, right. We've been hearing about how we should all be using XHTML and XML for ages. And yet... the web is still running on HTML 4.01.
Now, I suppose you could blame Internet Explorer for not properly supporting XHTML (it treats it as XML and displays the DOM if you try and do it properly, serving XHTML as "text/html" is wrong and broken). I haven't actually checked to see if the new IE7 supports XHTML properly, but, even if it does, XHTML doesn't really solve anything. It doesn't make data mining any easier. It's just HTML with end tags required.
What's really interesting, IMHO, is CSS3 and XML. You can style XML documents with CSS, which means you could conceivably have a document that describes the contents of the page in a fairly "semantic" manner (I think someone just won Buzzword Bingo here) and then is styled based on CSS for proper display.
You can already do something like that with XSLT, but XSLT has never seemed to really catch on, possibly because it's fairly complicated. With XML and CSS, it uses essentially the exact same semantics that HTML and CSS do (other than having no defaults), and you can apply most of the same styling knowledge from using CSS with HTML to using CSS with XML. The Content Creation section of CSS3 offers some really interesting possibilities.
Of course, without Internet Explorer support, this is basically useless, but it's still something that's fun to play around with, if not practical. But it does mean that we're still going to be using an HTML-based web for the forseeable future.
If RedHat has to supply the keys used to sign Fedora Core 6 with the OS, the signature is completely useless.
Then you'll be glad to know it doesn't. The section on giving away keys says you only have to do that if the software won't run without your private key. If Red Hat created a system where you could only install their signed RPMs, then they'd have to give away the private key under the GPLv3. As long as you're allowed to install unsigned RPMs or to install RPMs signed with your own key, their private key can be kept private.
There are basically two anti-DRM clauses. They essentially say "the source you provide must be usable" and "modified versions must be able to read the same files as the original." So you can create DRMed files with GPLv3 software, but any modified version of the software must be capable of reading the file. (So it won't be a very useful DRM program, but...)
Sick and tired of seeing all these stupid fucking articles being posted to the homepage.
That's funny. This article wasn't posted to the front page, it was posted to the Games section. Yes, article stories now appear on the front page in a condensed form, but the articles in the gray boxes are specifically articles that interest a smaller group.
If you're not interested in a section, go to Preferences, Homepage, and disable it. You don't have to read articles you aren't interested in, that's the entire point behind sections.
The Japanese where every bit as sick and twisted as the Nazis. They just didn't kill as many white people.
I'd hesitate to use the word "the Japanese" because it means both the government in charge and the people. While you're absolutely correct that the Japanese government at the time did stuff that was every bit as nasty as the Nazis, the Japanese as a people are no more evil than the Germans as a people are or Americans as a people are.
BTW An honest portrayal of members of the Japanese military would could honestly make them out to be far worse monsters than they where ever made out in any WWII movie.
So what? Yes, individual people can be really messed in the head. That doesn't mean that everyone of the same race is messed up. Timothy McVeigh and the Unibomber certainly don't represent Americans. A movie about Timothy McVeigh wouldn't portray every other American as being just like him. That's the concept I'm trying to get across - your average American, German, or Japanese person isn't a brutal killer.
Yes, some Japanese decided to do some nasty things, and they got a lot of people to follow. The Nazis did the same thing to the Germans. Arguably, something similar happened in Abu Graib.
But more importantly, just because the Japanese government were doing evil things, doesn't mean that Japanese-Americans will be doing evil things. Your average Japanese citizen and average American citizen at the time of WWII were likely more similar than different. There would be a cultural difference, of course, but both would just be human.
A lot of people here have missed the point. Tom Sawyer and Huckleberry Finn may have contained the word "nigger" but they were not racist books. Anyone who thinks they are really needs to actually read them; while some of the characters definitely have racist views the books actually portray black people as, well, people. Tom Sawyer and Huck Finn find that, despite what the adults tell them, their actual experiences show that black people are just people, like them. There's racist speech and racist remarks made by characters in the books, but the books themselves are supposed to show how black people are really just people.
According to the article, GUN isn't like that. GUN instead portrays American Indians soley in a racist fashion. The characters in a period piece are allowed to be racist. It's expected that an American during World War II would hate Japanese. (But, interestingly enough, not Germans...) Japanese characters are allowed to be racist against Americans. However, Japanese characters in a World War II film shouldn't act like a racial stereotype. They should behave like a Japanese person during that time actually would.
Yes, you can't ignore racism. It's real, and it should be acknowledged. Pretending it doesn't exist is wrong. However, falling prey to it, and portraying the world based on racist views isn't right either. There's nothing wrong with having racist characters in a game. There is something wrong when the game itself reinforces the racial stereotypes.
The Association for American Indian Development contents that GUN reinforces racial stereotypes, and the article appears to agree. Having never played the game, I have no way of knowing if they're right, but if the game really does display American Indians as racial stereotypes, they have a valid point.
I'd buy that IF Square-Enix were a small game manufactorer. They aren't. They're a large game manufactorer. If one game, regardless of how popular, is enough to bump their profits by 300% for one year, they've got some serious issues.
And if you read the article, they're basically down in all sections, not just the section that produced DragonQuest VIII. For a company like Valve, where they don't make a lot of games, a single popular game should bump their profits by 300%. For a company like Square-Enix, where they make a lot of different games, having a single title be that important to their bottom line cannot be a good thing.
Especially because if you read the article, sales are up - but profits fell a massive amount.
Wait, so you're saying that DragonQuest VIII was enough to bump their profits over 300%?
A 70% decline (well, 67.7%) isn't a minor bump in the road, it's more of a large hole. Their profits dropped more than two-thirds. If one video game is capable of giving them that large a boost in profits, they have some serious problems.
Re:People are Obese regarless of Income or Geograp
on
Obesity Contagious?
·
· Score: 1
Get a Brita if you can't stand the taste of tap water, buy bottled water if you must spend money on your beverages.
Seltzer water is good too, if you really want something fizzy. The place I work has really nice water filter systems (far better than a Brita, but probably far more expensive) so I usually drink water at work. But at home, I've (tried) to switch all my soda over to flavored seltzers. 0 calories, still fizzy, with a mild taste.
As an added benefit, it's also cheaper than Coke.:)
Read the blog post. The author specifically specifies the GPLv3, and not just "the GPL." The blog title is "Thinking About GPL3..." and he links to a copy of the GPLv3 draft. (Which actually says "THIS IS A DRAFT" right on it, don't know why he linked a copy and not the GPLv3 site, but...)
So, yes - he's talking about using the GPLv3 as opposed to the current GPL.
Which is silly, because the GPLv3 is still in draft form. It's not released. Speculation about how to apply the GPLv3 would make sense, talking about actually releasing something under it is rather early. Unless he intentional means to say "we have no plans on releasing an open source version of Solaris until 2007."
The GPLv3 is still in draft form. It doesn't actually exist yet. The version on the FSF webpage could be better classified as a "beta" release (I think that's what Stallman considers it).
It's a little early to be saying "I'm going to be using the GPLv3!" Yes, they're working on it, but it's not actually out yet. The optimistic "release" date is November of this year, with the expected release date being early 2007... It's just not ready yet!
However, thinking about the current draft and any problems you have with it is encouraged. They want comments still, there's still time to help change the final draft. Saying "I'm going to use the GPLv3!" is still premature. Wait until it's actually finished, then decide.
Try an LXR search. Generally speaking, kungFuDeathGrip is used (as Pneuma ROCKS guessed) to ensure that reference counts are kept above 0 during a code path. A good example is in libpr0n, where the comment kind of explains what they're doing.
In XPCOM (and COM), objects have reference counts. When the reference count reaches 0, the object is destroyed. The reference count is incremented any time a block of code takes a reference to the object, and is decremented whenever a block of code releases that reference.
Occasionally there are places where the reference count is potentially 1, and a certain function call may reduce it to 0 (thereby destroying the object) before the object is really ready to be destroyed. In that case, the Mozilla codebase grabs a kungFuDeathGrip on the object (increasing the ref count by 1) until it's really safe to release the object.
Generally speaking this occurs when an object (event source) makes a callback on another object with a refcount of 1 (event handler), and the event handler removes itself from the event source - reducing its refcount to 0. However, if the event handler isn't complete yet (still has some cleanup), then they need to grab a kungFuDeathGrip to ensure that the object isn't destroyed before it's ready to be destroyed.
I wonder if this means they'll slowly start to rid themselves of the "NS" prefix that's everywhere inside the code base...
All XPCOM interfaces start with "nsI," cross-platform support is based on the "Netscape Portable Runtime," most functions start with "NS_"...
I wonder if they have any plans to slowly transition over to "mozI" or "Moz_"? Somehow I doubt it (massive plugin breakage), but still - the remains of Netscape are still all over the code.
Given the general weirdness of the US copyright system, I expect that it's entirely possible to have a copyright to an encryption key. Even so, it doesn't matter: you can't compel his to give it up (he has no contract with you) and so Section 12 kicks in: you can't legal distribute the code, so you can't distribute the code at all.
You fight your own shadow on the end of II... I don't know anyone but me who beat the second adventure of Zelda I.
I did. I'm pretty sure everyone else in my family did too, including my mother and father, although I could be wrong. (I know they actually played some ways into it, but I'm not sure how far into it.) I think Zelda remains the only video game that everyone in my family actually played together, since the Nintendo was new and cool at the time.
I've since repeated through both adventures on the NES Classics version of the original Zelda for GBA.
Or is it that if I also distribute everything needed to remake my secure OS with another private key, I qualify for the requirement ?
That's exactly correct. The current draft contains this sentence:
Complete Corresponding Source Code need not include anything that users can regenerate automatically from other parts of the Complete Corresponding Source Code.
The requirement is simply that people you distribute the GPLv3ed software to must be able to actually use that source code. If you give out source code that can't run because you're leaving out some vital part, that violates the GPLv3. They sort of clarify it in the rational behind Section 1 (although that's kinda confusing, IMO).
You have to include everything required for the recipient of the code to actually build a working version of the program (minus system libraries like the C runtime). It's to prevent someone from releasing something under the GPL that just so happens to require a third-party library that's closed, or that can't run without some private encryption key.
As long as it's possible to create a working copy of the program from the data you distribute, you don't have to distribute anything more.
Nice try, but it wouldn't work. You don't have legal rights to Linus' key. Section 12 states that if you cannot legally meet the obligations of the license (in this case, giving out Linus' key), you cannot distribute the code at all.
Since you can't force Linus to give up his key (it's under his copyright, and there's no obligation for him to give it up under the GPLv3), you simply can't distribute your embedded device to anyone with the GPLv3ed software included. Doing so would be a violation of the GPLv3.
The only time that you would have to give up a key is if you distribute the code in such a way that a key is required for custom modifications to work. Trying to do so using a key you don't have rights to falls prey to Section 12, meaning you can't distribute the software at all.
I'm sorry, but I can't figure out what your point is. First off, that's from three years ago, well before the current draft was written let alone released. Secondly, the GPLv3 is quite clear that simply signing a binary is allowed. The only restriction is if the end-user must use an otherwise unavailable private key in order to actually run the program.
Someone can sign their build of a kernel. There's no GPLv3 violation in doing so and distributing that binary, because the signature isn't required to actually use the signed kernel. Likewise, someone can set up their system to only run certain signed code. It's their private system, and the GPLv3 doesn't apply to how the software is used, only distributed.
The only time a key must be revealed is if the program flat-out won't run without it. The entire purpose to Section 1 is to say that you have to give people enough to actually run the GPLed program after distributing it to them. That's all it says.
He misinterpreted part of the GPLv3. The private key section says that if private keys are required for the code to function (in other words, your program will only load signed code) than you must make available a means to generate the signed code. The theory here is that certain hardware devices (*cough*TiVo*cough*) use GPLed software, but make it impossible to actually modify and run that software on their hardware device. In order to allow people to make changes and actually use those changes, you have to make available any private keys required to make the code actually run.
So if Mr. Torvalds has a private key that he uses to sign code, he is under no obligation to release that key to the public assuming that an end user can build and run the code without requiring the private key. You only have to release your private key if a third-party build of the software will not run without being signed by that key.
Now, another common misinterpretation that came up at the GPLv3 launch was that this meant that if you had set up your system to require signed code that you would have to make your private key available. This isn't the case. The only requirement is that a third party must be able to build and run the system without your private key. If this requires them to generate their own private key, that's perfectly acceptable.
If a GPLv3ed program cannot run without a specific private key, that private key must be made available. That's all the license says. Developers are not required to disclose private keys that they use to sign code.
IE is decoupled from the OS in the same way Mozilla is decoupled from the OS, assuming you define OS as "kernel." IE is part of the shell, though. Removing IE would break a lot of the existing shell.
IE is part of Windows in the same way Konqueror is part of KDE. (Wow, a lot of other people came up with that while I wrote this!:)) If you removed Konqueror from KDE - actually, I'm not really sure how that would ripple, but the concept is the same. I think Konqueror handles the desktop in the same way Nautilus runs the GNOME desktop and IE runs the Windows desktop. (That is, it is the application that draws the desktop background and all the pretty icons on the desktop.) Removing it would cause problems with Windows applications because it's assumed to be part of the platform.
In the case of the Linux desktops, you could probably hack something together that would work without those components. Arguably you could in Windows too, I guess, by having the Task Manager open (since it allows you to run programs by filename). But Windows is designed as a distribution to use IE as the main shell program. If you kill IE in Windows (go to Task Manager, find "explorer.exe", and kill it - or just crash it, there are plenty of ways to do it), you lose the desktop, the Start menu, and the taskbar. IE is the shell that most people interact with. (It's worth pointing out that "iexplore.exe" is a stub program that essentially just runs "explorer.exe".)
However, even though IE is the shell, it's not MSHTML. (Confused yet?) IE actually hosts MSHTML as an ActiveX control. (Yes, OLE is still around - it's now ActiveX.) So in that sense, the HTML component is decoupled from the shell as you'd expect. However, MSHTML currently gets used to draw the desktop (remember Active Desktop?) and the file view in Windows Explorer. (Google "desktop.ini" for information on how to muck with the HTML displayed in folder views.) Arguably they could separate the two, and recreate the file browser without the HTML rendering capabilities.
However, most of this is really a moot point. The majority of times IE is used as an infection vector is when IE is being used as an Internet browser. (The others have to do with the folder view "previewing" certain files, an annoying habit that Nautilus shares. At one point there was a buffer overflow in the ID3 handler, allowing a malicious MP3 to infect you simply by selecting it.) Removing it from the shell wouldn't help much, since it's the use of it as a browser that gets most people. In that respect, switching to Firefox is usually enough to protect you from IE's flaws.
This was actually awarded ages ago (OK, more like a week ago) at the GPLv3 launch. I happened to be sitting one row in front of where he was sitting when they called him up (which was kinda neat, I guess). I never did get to see what the actual award was there because the thing was rolled up, and he never unrolled. So it's nice to see the picture on the website.
I'll have to check to see if I have any pictures of the award ceremony. I think I might have one of him actually holding the thing. However I haven't gotten around to dumping my camera yet, so I'm not sure.
They should also be announcing (any day now) the winner of the FSF Award for the Advancement of Free Software, which was also awarded at the GPLv3 launch. If I had been paying closer attention, I could tell you if it was Wikimedia that won, or Wikipedia. I think I also have pictures of that award being accepted.
Hehe, both my parents completed both quests of the original Zelda. In fact, I think everyone in my immediate family has actually completed the entire original Zelda - including my parents and sister, who aren't really "gamers." (Guess it was the novelty of the thing.)
About the only place we got stuck was when you had to blow the whistle to discover the 7th palace. Yeah, that made sense.
I dunno about my father, but my mother would probably have laughed at someone who thought the original Zelda was "too hard":).
All of us were sad when the battery in that little pack finally died and the game was no longer playable. Fortunately we've got emulators now and I've got the NES Classic series to get my fix. No more worries about a dead battery killing your save game. (The GBA carts use flash memory, right?)
OMG, you mean the level of technology in general improved along with the invention of the phone? And, yeah, before the phone, fires used to be a really big deal. With the invention of the telephone, the steam engine, and a whole host of other things, fires are no longer the city-destroying events they used to be.
The police weren't patrolling to stop crime - they stepped up patrolling to catch things like fire and medical emergencies. Since someone with a heart attack couldn't just dial 911, they were hoping instead that they would be able to flag down a police officer who could then use their radio to call in the paramedics.
Yeah, you're right, life did go on before telephones. However, it was a lot more dangerous than it is with telephones. I, for one, rather like the advances in emergency response.
Slashdot Mirror
I dunno, stuff like <verse>, <title>, and perhaps most useful, <author> - keep in mind we're talking about computerized semantics, not human readability.
The "semantic web" already runs mostly on magic - theoretically, people mark up sections of their document as having certain meanings (like an author) and then the "semantic browser" picks up on those. In this case, it might pick up on the author and allow searching for other stuff by the same author. Realistically, who is going to bother tagging their document by hand?
What's really more useful with XML and CSS is just making things clearer internally, so instead of doing something like <div class="title">, <div class="verse">, and so on, you'd just do <title>, <verse>, and so on. One of the main things CSS has done is made it so that more and more complicated webpages are becoming a mesh of <div>s and <span>s, making any semantic meaning that HTML has totally meaningless. (You gotta love <span class="bold"> over <b> as if that's somehow an improvement.)
Actually, they say that the XHTML 1.0 mappings to "tag soup" can be marked as "text/html" but those markings are horrible anyway (and, best of all, invalid HTML 4.01). Calling XHTML "text/html" is still essentially broken. It's supposed to allow XHTML to be viewed with browsers that don't support XHTML, but it essentially removes the only advantage of XHTML - syntax checking.
It's always fun to take an "XHTML 1.0 site" and run it through an XML parser, see how far it gets before bombing. The "draconian error handling" essentially guarentees that it'll never take off, or even if it does, that most browsers will start allowing worse and worse XHTML.
You do know that there are more XML schemas out there than just XHTML, right? There's no reason why you can't simply include xsi:schemaLocation and explain exactly what your XML contains. That's the entire point behind XML schemas. Theoretically, you can import various other schemas, so even if your site uses some custom XML markup, your schema can reference known other schemas and still make the data semantically meaningful.
However, suggesting that XHTML is magically more meaningful than a random XML document when it comes to semantics is just laughable. If you're trying to look at just the text, HTML offers various semantic meanings for the various tags. But if you want to go any further, like recognizing certain portions as addresses, XHTML offers no help. <div class="zipcode">1234</div> isn't any more semantically useful than <zipcode>1234</zipcode> - both require you to know the design of the specific document to be helpful.
Yeah, right. We've been hearing about how we should all be using XHTML and XML for ages. And yet... the web is still running on HTML 4.01.
Now, I suppose you could blame Internet Explorer for not properly supporting XHTML (it treats it as XML and displays the DOM if you try and do it properly, serving XHTML as "text/html" is wrong and broken). I haven't actually checked to see if the new IE7 supports XHTML properly, but, even if it does, XHTML doesn't really solve anything. It doesn't make data mining any easier. It's just HTML with end tags required.
What's really interesting, IMHO, is CSS3 and XML. You can style XML documents with CSS, which means you could conceivably have a document that describes the contents of the page in a fairly "semantic" manner (I think someone just won Buzzword Bingo here) and then is styled based on CSS for proper display.
You can already do something like that with XSLT, but XSLT has never seemed to really catch on, possibly because it's fairly complicated. With XML and CSS, it uses essentially the exact same semantics that HTML and CSS do (other than having no defaults), and you can apply most of the same styling knowledge from using CSS with HTML to using CSS with XML. The Content Creation section of CSS3 offers some really interesting possibilities.
Of course, without Internet Explorer support, this is basically useless, but it's still something that's fun to play around with, if not practical. But it does mean that we're still going to be using an HTML-based web for the forseeable future.
Then you'll be glad to know it doesn't. The section on giving away keys says you only have to do that if the software won't run without your private key. If Red Hat created a system where you could only install their signed RPMs, then they'd have to give away the private key under the GPLv3. As long as you're allowed to install unsigned RPMs or to install RPMs signed with your own key, their private key can be kept private.
There are basically two anti-DRM clauses. They essentially say "the source you provide must be usable" and "modified versions must be able to read the same files as the original." So you can create DRMed files with GPLv3 software, but any modified version of the software must be capable of reading the file. (So it won't be a very useful DRM program, but...)
That's funny. This article wasn't posted to the front page, it was posted to the Games section. Yes, article stories now appear on the front page in a condensed form, but the articles in the gray boxes are specifically articles that interest a smaller group.
If you're not interested in a section, go to Preferences, Homepage, and disable it. You don't have to read articles you aren't interested in, that's the entire point behind sections.
So what? Yes, individual people can be really messed in the head. That doesn't mean that everyone of the same race is messed up. Timothy McVeigh and the Unibomber certainly don't represent Americans. A movie about Timothy McVeigh wouldn't portray every other American as being just like him. That's the concept I'm trying to get across - your average American, German, or Japanese person isn't a brutal killer.
Yes, some Japanese decided to do some nasty things, and they got a lot of people to follow. The Nazis did the same thing to the Germans. Arguably, something similar happened in Abu Graib.
But more importantly, just because the Japanese government were doing evil things, doesn't mean that Japanese-Americans will be doing evil things. Your average Japanese citizen and average American citizen at the time of WWII were likely more similar than different. There would be a cultural difference, of course, but both would just be human.
A lot of people here have missed the point. Tom Sawyer and Huckleberry Finn may have contained the word "nigger" but they were not racist books. Anyone who thinks they are really needs to actually read them; while some of the characters definitely have racist views the books actually portray black people as, well, people. Tom Sawyer and Huck Finn find that, despite what the adults tell them, their actual experiences show that black people are just people, like them. There's racist speech and racist remarks made by characters in the books, but the books themselves are supposed to show how black people are really just people.
According to the article, GUN isn't like that. GUN instead portrays American Indians soley in a racist fashion. The characters in a period piece are allowed to be racist. It's expected that an American during World War II would hate Japanese. (But, interestingly enough, not Germans...) Japanese characters are allowed to be racist against Americans. However, Japanese characters in a World War II film shouldn't act like a racial stereotype. They should behave like a Japanese person during that time actually would.
Yes, you can't ignore racism. It's real, and it should be acknowledged. Pretending it doesn't exist is wrong. However, falling prey to it, and portraying the world based on racist views isn't right either. There's nothing wrong with having racist characters in a game. There is something wrong when the game itself reinforces the racial stereotypes.
The Association for American Indian Development contents that GUN reinforces racial stereotypes, and the article appears to agree. Having never played the game, I have no way of knowing if they're right, but if the game really does display American Indians as racial stereotypes, they have a valid point.
It's just as well. Maat can go to hell.
I'd buy that IF Square-Enix were a small game manufactorer. They aren't. They're a large game manufactorer. If one game, regardless of how popular, is enough to bump their profits by 300% for one year, they've got some serious issues.
And if you read the article, they're basically down in all sections, not just the section that produced DragonQuest VIII. For a company like Valve, where they don't make a lot of games, a single popular game should bump their profits by 300%. For a company like Square-Enix, where they make a lot of different games, having a single title be that important to their bottom line cannot be a good thing.
Especially because if you read the article, sales are up - but profits fell a massive amount.
Wait, so you're saying that DragonQuest VIII was enough to bump their profits over 300%?
A 70% decline (well, 67.7%) isn't a minor bump in the road, it's more of a large hole. Their profits dropped more than two-thirds. If one video game is capable of giving them that large a boost in profits, they have some serious problems.
Seltzer water is good too, if you really want something fizzy. The place I work has really nice water filter systems (far better than a Brita, but probably far more expensive) so I usually drink water at work. But at home, I've (tried) to switch all my soda over to flavored seltzers. 0 calories, still fizzy, with a mild taste.
As an added benefit, it's also cheaper than Coke. :)
Read the blog post. The author specifically specifies the GPLv3, and not just "the GPL." The blog title is "Thinking About GPL3..." and he links to a copy of the GPLv3 draft. (Which actually says "THIS IS A DRAFT" right on it, don't know why he linked a copy and not the GPLv3 site, but...)
So, yes - he's talking about using the GPLv3 as opposed to the current GPL.
Which is silly, because the GPLv3 is still in draft form. It's not released. Speculation about how to apply the GPLv3 would make sense, talking about actually releasing something under it is rather early. Unless he intentional means to say "we have no plans on releasing an open source version of Solaris until 2007."
The GPLv3 is still in draft form. It doesn't actually exist yet. The version on the FSF webpage could be better classified as a "beta" release (I think that's what Stallman considers it).
It's a little early to be saying "I'm going to be using the GPLv3!" Yes, they're working on it, but it's not actually out yet. The optimistic "release" date is November of this year, with the expected release date being early 2007... It's just not ready yet!
However, thinking about the current draft and any problems you have with it is encouraged. They want comments still, there's still time to help change the final draft. Saying "I'm going to use the GPLv3!" is still premature. Wait until it's actually finished, then decide.
Try an LXR search. Generally speaking, kungFuDeathGrip is used (as Pneuma ROCKS guessed) to ensure that reference counts are kept above 0 during a code path. A good example is in libpr0n, where the comment kind of explains what they're doing.
In XPCOM (and COM), objects have reference counts. When the reference count reaches 0, the object is destroyed. The reference count is incremented any time a block of code takes a reference to the object, and is decremented whenever a block of code releases that reference.
Occasionally there are places where the reference count is potentially 1, and a certain function call may reduce it to 0 (thereby destroying the object) before the object is really ready to be destroyed. In that case, the Mozilla codebase grabs a kungFuDeathGrip on the object (increasing the ref count by 1) until it's really safe to release the object.
Generally speaking this occurs when an object (event source) makes a callback on another object with a refcount of 1 (event handler), and the event handler removes itself from the event source - reducing its refcount to 0. However, if the event handler isn't complete yet (still has some cleanup), then they need to grab a kungFuDeathGrip to ensure that the object isn't destroyed before it's ready to be destroyed.
I wonder if this means they'll slowly start to rid themselves of the "NS" prefix that's everywhere inside the code base...
All XPCOM interfaces start with "nsI," cross-platform support is based on the "Netscape Portable Runtime," most functions start with "NS_"...
I wonder if they have any plans to slowly transition over to "mozI" or "Moz_"? Somehow I doubt it (massive plugin breakage), but still - the remains of Netscape are still all over the code.
Given the general weirdness of the US copyright system, I expect that it's entirely possible to have a copyright to an encryption key. Even so, it doesn't matter: you can't compel his to give it up (he has no contract with you) and so Section 12 kicks in: you can't legal distribute the code, so you can't distribute the code at all.
I did. I'm pretty sure everyone else in my family did too, including my mother and father, although I could be wrong. (I know they actually played some ways into it, but I'm not sure how far into it.) I think Zelda remains the only video game that everyone in my family actually played together, since the Nintendo was new and cool at the time.
I've since repeated through both adventures on the NES Classics version of the original Zelda for GBA.
That's exactly correct. The current draft contains this sentence:
The requirement is simply that people you distribute the GPLv3ed software to must be able to actually use that source code. If you give out source code that can't run because you're leaving out some vital part, that violates the GPLv3. They sort of clarify it in the rational behind Section 1 (although that's kinda confusing, IMO).
You have to include everything required for the recipient of the code to actually build a working version of the program (minus system libraries like the C runtime). It's to prevent someone from releasing something under the GPL that just so happens to require a third-party library that's closed, or that can't run without some private encryption key.
As long as it's possible to create a working copy of the program from the data you distribute, you don't have to distribute anything more.
Nice try, but it wouldn't work. You don't have legal rights to Linus' key. Section 12 states that if you cannot legally meet the obligations of the license (in this case, giving out Linus' key), you cannot distribute the code at all.
Since you can't force Linus to give up his key (it's under his copyright, and there's no obligation for him to give it up under the GPLv3), you simply can't distribute your embedded device to anyone with the GPLv3ed software included. Doing so would be a violation of the GPLv3.
The only time that you would have to give up a key is if you distribute the code in such a way that a key is required for custom modifications to work. Trying to do so using a key you don't have rights to falls prey to Section 12, meaning you can't distribute the software at all.
I'm sorry, but I can't figure out what your point is. First off, that's from three years ago, well before the current draft was written let alone released. Secondly, the GPLv3 is quite clear that simply signing a binary is allowed. The only restriction is if the end-user must use an otherwise unavailable private key in order to actually run the program.
Someone can sign their build of a kernel. There's no GPLv3 violation in doing so and distributing that binary, because the signature isn't required to actually use the signed kernel. Likewise, someone can set up their system to only run certain signed code. It's their private system, and the GPLv3 doesn't apply to how the software is used, only distributed.
The only time a key must be revealed is if the program flat-out won't run without it. The entire purpose to Section 1 is to say that you have to give people enough to actually run the GPLed program after distributing it to them. That's all it says.
He misinterpreted part of the GPLv3. The private key section says that if private keys are required for the code to function (in other words, your program will only load signed code) than you must make available a means to generate the signed code. The theory here is that certain hardware devices (*cough*TiVo*cough*) use GPLed software, but make it impossible to actually modify and run that software on their hardware device. In order to allow people to make changes and actually use those changes, you have to make available any private keys required to make the code actually run.
So if Mr. Torvalds has a private key that he uses to sign code, he is under no obligation to release that key to the public assuming that an end user can build and run the code without requiring the private key. You only have to release your private key if a third-party build of the software will not run without being signed by that key.
Now, another common misinterpretation that came up at the GPLv3 launch was that this meant that if you had set up your system to require signed code that you would have to make your private key available. This isn't the case. The only requirement is that a third party must be able to build and run the system without your private key. If this requires them to generate their own private key, that's perfectly acceptable.
If a GPLv3ed program cannot run without a specific private key, that private key must be made available. That's all the license says. Developers are not required to disclose private keys that they use to sign code.
IE is decoupled from the OS in the same way Mozilla is decoupled from the OS, assuming you define OS as "kernel." IE is part of the shell, though. Removing IE would break a lot of the existing shell.
IE is part of Windows in the same way Konqueror is part of KDE. (Wow, a lot of other people came up with that while I wrote this! :)) If you removed Konqueror from KDE - actually, I'm not really sure how that would ripple, but the concept is the same. I think Konqueror handles the desktop in the same way Nautilus runs the GNOME desktop and IE runs the Windows desktop. (That is, it is the application that draws the desktop background and all the pretty icons on the desktop.) Removing it would cause problems with Windows applications because it's assumed to be part of the platform.
In the case of the Linux desktops, you could probably hack something together that would work without those components. Arguably you could in Windows too, I guess, by having the Task Manager open (since it allows you to run programs by filename). But Windows is designed as a distribution to use IE as the main shell program. If you kill IE in Windows (go to Task Manager, find "explorer.exe", and kill it - or just crash it, there are plenty of ways to do it), you lose the desktop, the Start menu, and the taskbar. IE is the shell that most people interact with. (It's worth pointing out that "iexplore.exe" is a stub program that essentially just runs "explorer.exe".)
However, even though IE is the shell, it's not MSHTML. (Confused yet?) IE actually hosts MSHTML as an ActiveX control. (Yes, OLE is still around - it's now ActiveX.) So in that sense, the HTML component is decoupled from the shell as you'd expect. However, MSHTML currently gets used to draw the desktop (remember Active Desktop?) and the file view in Windows Explorer. (Google "desktop.ini" for information on how to muck with the HTML displayed in folder views.) Arguably they could separate the two, and recreate the file browser without the HTML rendering capabilities.
However, most of this is really a moot point. The majority of times IE is used as an infection vector is when IE is being used as an Internet browser. (The others have to do with the folder view "previewing" certain files, an annoying habit that Nautilus shares. At one point there was a buffer overflow in the ID3 handler, allowing a malicious MP3 to infect you simply by selecting it.) Removing it from the shell wouldn't help much, since it's the use of it as a browser that gets most people. In that respect, switching to Firefox is usually enough to protect you from IE's flaws.
This was actually awarded ages ago (OK, more like a week ago) at the GPLv3 launch. I happened to be sitting one row in front of where he was sitting when they called him up (which was kinda neat, I guess). I never did get to see what the actual award was there because the thing was rolled up, and he never unrolled. So it's nice to see the picture on the website.
I'll have to check to see if I have any pictures of the award ceremony. I think I might have one of him actually holding the thing. However I haven't gotten around to dumping my camera yet, so I'm not sure.
They should also be announcing (any day now) the winner of the FSF Award for the Advancement of Free Software, which was also awarded at the GPLv3 launch. If I had been paying closer attention, I could tell you if it was Wikimedia that won, or Wikipedia. I think I also have pictures of that award being accepted.
Hehe, both my parents completed both quests of the original Zelda. In fact, I think everyone in my immediate family has actually completed the entire original Zelda - including my parents and sister, who aren't really "gamers." (Guess it was the novelty of the thing.)
About the only place we got stuck was when you had to blow the whistle to discover the 7th palace. Yeah, that made sense.
I dunno about my father, but my mother would probably have laughed at someone who thought the original Zelda was "too hard" :).
All of us were sad when the battery in that little pack finally died and the game was no longer playable. Fortunately we've got emulators now and I've got the NES Classic series to get my fix. No more worries about a dead battery killing your save game. (The GBA carts use flash memory, right?)
OMG, you mean the level of technology in general improved along with the invention of the phone? And, yeah, before the phone, fires used to be a really big deal. With the invention of the telephone, the steam engine, and a whole host of other things, fires are no longer the city-destroying events they used to be.
The police weren't patrolling to stop crime - they stepped up patrolling to catch things like fire and medical emergencies. Since someone with a heart attack couldn't just dial 911, they were hoping instead that they would be able to flag down a police officer who could then use their radio to call in the paramedics.
Yeah, you're right, life did go on before telephones. However, it was a lot more dangerous than it is with telephones. I, for one, rather like the advances in emergency response.