It has already been pointed out that HTML did evolve a lot. I'd like to add that the ecosystem it's part of has also evolved.
HTML 4 as written in 2011 is vastly different from HTML 4 written in 1997 (for instance, we tend not to write our sites for a specific version of a specific browser anymore). CSS as written in 2011 is vastly different from CSS written in 1996; for instance, before we had vendor prefixes we had to use hacks to present different CSS depending on browser and sometimes browser version. XHTML hasn't changed any since XHTML 1.0 but that's because XHTML 1.1 is so problematic to use that nobody uses it. JavaScript changed a lot in the last few years; I can still remember a time when using JS for anything important was a big no-no while today relying on JS isn't even neccessarily a barrier to a barrier-free site.
Nowadays web development even includes using technology that isn't widely supported yet - the magic of polyfills (another very young term) allows me to write a site that uses HTML5 features and still works on browsers that have no concept of HTML5. A few years ago any manipulation of the DOM was done by hand-written JS; today we ask Google for an instance of jQuery and use that.
Yes, I'm still using HTML 4.01, just like in 1999. But I'm no longer putting noise into my stylesheets to trigger IE parser bugs. I'm no longer limited to one-bit transparency because IE6 doesn't understand PNG alpha channels. I don't have to worry about whether an element has layout. And, quite frankly, if I wrote things like <script language="javascript"> today nobody would take me seriously as a web developer.
Saying that tech skills never age because languages stick around is like saying that the operating system as a concept is dead - after all, the market is utterly dominated by Windows and Unix, which have been around since 1981 and 1969, respectively. You'd think that they'd have come up with something new in the last thirty years.
There is a market for people who know old (versions of) languages but it's not identical with the market for people who know the current state of the art.
Well, I did start my sentence with "and if you don't go the C compatibility route", so we already were in a situation where "do like C does" is not an option.
Just for the record, I use "if (foo)" a lot and I like the construct. I don't use it a lot for comparisons against zero (false and null being much more common) but I can see how allowing zero in is a useful bit of syntactic sugar.
And if you don't go the C compatibility route, wouldn't it make more sense to throw an exception when trying to treat a non-boolean like a boolean instead of saying "everything but boolean true is false"?
Anyway, I just googled it and it appears that this behavior has been accepted as a bug. Well, partially. If the bug is fixed as requested in the bug report, everything will default to true now, with only null and false being false.
Then again, the setup time for a mail filter is less than a minute and it allows implicit searches, such as "What were the last five invoices sent to me by PayPal?". With a search function you need to look up which address PayPal uses to send invoices and then search for that. (Depending on which kind of mails you send/receive, just searching for "PayPal" might generate too many false matches.) With a folder fed by a filter tuned to that address you need one click. Oh, and once the filter is in place, having all existing matching mails categorized by it just requires running it on your inbox once.
To me, folders are two things: Firstly they are a way of visualizing metadata about my mails. Mails from my workplace have a higher priority than mails from Slashdot; having them filed at retrieval means that even a deluge of/. mails can't crowd out more important mails. Filing always happens by filter; I never move mails by hand. Secondly they are mutually-exclusive search optimizations; a few searches are greatly simplified by having all mails on a particular topic pre-grouped.
Of course all of this does nothing to keep me from using searches, which I do. Thunderbird constructs a fulltext index so I can always search across all folders without losing performance or I can filter inside a folder. Folders and the search function are tools with different capabilities and purposes; there's some overlap but even there they are hardly mutually exclusive.
Now, I can understand the argument against manually-maintained folders. That takes time for every mail and most likely doesn't do anything a filter couldn't do better.
You said "tl;dr", but then posted something 5x as long.
I followed the "tl;dr" with a colon followed by a very brief version of my post. You may not be aware of it but "tl;dr:" is a converntion used to denote that a heavily abbreviated version of the post follows, used to preempt such statements. I admit that most people use it at the end of their posts, not the beginning, but I wanted to make clear right away what my post was supposed to express.
Power plants are "terminal" storage sites. As demonstrated at Fukushima, where they stored far more waste than fuel. As at practically every reactor in the US, and probably elsewhere. After a half century, it's obvious that's how we do it. Any other "plans" are science fiction or worse.
Still, most nuclear power plants are not entirely surrounded by rock. The post you replied to explicitly talked about underground storage sites. It does not matter whether these are currently used or even close; your reply does not work as you implicitly assumed that all storage sites are power plants in the context of a discussion about sites that aren't.
You could have replied with what you just wrote: That practical underground storage is nowhere near widespread implementation. That would have been a valid reply and could have been used as a bridge to the arguments you did make. Instead you argued that underground storage can't be safe because power plants can explode.
Again: My argument is not about the safety of nuclear power plants or current waste storage practices. It's about the semantics of your argument. Your argument was not wrong, it was used in a context where it didn't make sense because you didn't explain a premise you introduced.
Your sarcasm was inane, talking like Fukushima's waste storage was a unique situation. The fact is that waste is stored onsite. Then the site does get damaged, as Fukushima has most recently and undeniably demonstrated, and the radiation moves more than the few inches the earlier post tried to assure us was the safe and sound case.
We had a post talking about how proposed permanent underground storage facilities are a bad idea. Then we had a reply to that asserting that in these underground facilities the nuclear waste won't go anywhere, unlike CO2. Then you replied to that with a post based on what happened when a nucelar power plant exploded.
It doesn't matter how close we are to storing nuclear waste underground, the discussion was about the behavior of nuclear waste when stored underground, not about current waste storage practices.
You'd 'assume that "an explosion or fire disperses the waste over a large area" is a rather unlikely scenario.' even though it's eventual certainty was just proven at Fukushima.
I also made certain to point out that I was talking about underground storage facilities, nut power plants.
You haven't even bothered to acknowledge that in my last post I set you straight on the most basic reading comprehension.
No, you just unilaterally decided that the discussion was about something nobody else thought it was, then were surprised when people were talking about underground storage facilities and not power plants. You only introduced your premise that all storage facilities are power plants in your last post.
You are full of shit. Why should I care about your concern that in the long term people might not accept my arguments, when your reasons for doing so are that you're full of shit?
You're a crackpot, or worse. Since you won't shut up, I'm not giving you an excuse for posting more bullshit. Goodbye.
tl;dr: You misunderstood the GGP. The GGP argues about terminal storage sites, not power plants. I'm arguing that your arguments don't apply because of that, not because of their veracity.
Even after seeing the undeniable evidence you weren't aware that's what they do?
I saw undeniable evidence for them storing nuclear waste onsite. I never saw any evidence for any plans to never move that waste anywhere else, as the term "permanent storage" would imply. Now, most waste does only get shuffled around to temporary storage sites because it turns out that speccing out a permanent facility is really hard and takes ages. But that doesn't mean that any given NPP qualifies as a terminal storage site.
They also like to store nuke waste in nuke plants that get hit by earthquakes. You probably missed that in Virginia last month, too. And the one in Nebraska that the month before was a few inches from being flooded and facing the same pump failures that widely dispersed nuke waste in Japan.
The meltdown didn't cause widespread dispersal of the nuke waste in Fukushima. It was the explosion and fires. But so what? Each reactor is different, each has a variety of threats, and already several this year in the US have come within reach of what we saw in Fukushima just a little earlier. All of which have a terrible cost when those risks finally materialize, as we see in these plants that have been corruptly extended far beyond their designed or originally permitted operating lifetime.
You keep supplying arguments for an entirely different argument (safety of nuclear power plants) while trying to argue about the safety of terminal nuclear waste storage facilities.
I don't doubt that NPPs have issues, especially older ones that should be replaced. We are arguing, however, about whether nuclear waste stored in a terminal storage site has the potential of irradiating more than just its immediate vincinity. Which I also never called into question.
Given that terminal storage site plans usually call for the waste to be stored under conditions that make a runaway reaction extremely unlikely or impossible and for no volatile compounds or machinery to be near the waste and that the whole facility is underground, I'd assume that "an explosion or fire disperses the waste over a large area" is a rather unlikely scenario. Likewise, just about all scenarios relevant to NPPs are irrelevant here because NPPs behave fundamentally different to terminal storage sites.
There are other scenarios that we need to worry about, such as rain seeping through the facility and carrying some of the waste into the ground water. Trying to argue that since NPPs can explode, so can any other facility involving nuclear fuel is useless - it's like arguing that there is a significant risk of traffic accidents inside a car factory because there's a lot of cars there. That doesn't mean I'm arguing that car factories and highways are harmless; I'm arguing that car factories are dangerous in a different way and highways are not car factories.
But the risks, however real, are not what I was talking about. I was debunking the other lie about how nuke waste is dangerous only within a few inches. Which Fukushima just demonstrated, and intolerable cost, is just a lie. Now you're moving the goalposts, another favorite fallacy you nuke fetishists favor.
No, you just apparently misunderstood the GPP. The GPP's post talked about how nuclear waste behaves when underground, as made obvious by the statement that the radiation only "radiates a few centimetres in the rock". The statement made was that nuclear waste is solid and will not move much when the conditions of its storage facility change slightly. CO2, being a gas, will immediately seep out if a crack forms.
Now, there are valid arguments against that. For instance, water is not solid, will happily seep through any cracks that form and will erode the containers until
I wasn't aware that the preferred means of permanently storing nuclear waste was to have a tsunami hit a badly-maintained nuclear power plant. (I am aware that NPPs store some waste onsite but that's neither intended not in any way related to permanent storage plans.)
Most or all permanent nuclear storage facilities have flaws but the possibility of a meltdown causing widespread dispersal is not one of them. Whether your point is valid or not, using badly-researched arguments to make it will make you look like a crackpot.
Admittedly, the prequel trilogy did a lot to point out that George Lucas can be silly, too. I was thinking back to the Nineties when Star Wars was still respected and George Lucas was seen as a decent filmmaker.
From the prespective of someone who only became aware of Trek when TNG rolled around, things are a bit different.
Wars is the serious, mature one. It's about a war, with all that entails, which Trek only got close to during DS9 (which has a rather mixed reputation due to its darker tone). Trek has always been a wacky trip through the galaxy and when something nasty shows up it's usually resolved or postponed at the end of the episode.
Plus, Wars is the ultra-successful money-making machine while Trek is more of a reliable investment - Trek will have its series, which will always run seven seasons (excluding TOS*, TAS** and ENT***), and will also have a movie every now and then. Wars, meanwhile, has its movies, which are guaranteed to make tons of money, plus a bunch of other fluff.
Star Wars was even "around" before Trek. Star Wars came out in 1977 while the earliest bit of Trek us youngsters are usually exposed to is Star Trek: The Motion Picture from 1979. Yes, there was TOS, but most people only know it as meta-lore. In fact, what got most people my age (20-30) hooked on Trek wasn't the movies but TNG, which only appeared in 1987, well after the original Wars trilogy was done.
Plus, it's not like TOS was that successful. Granted, it lasted for three seasons but it was never a reliable ratings generator like TNG, DS9 and VOY.
* Like Firefly it generated most of its fame after its death.
** It's a Filmation spinoff series. 'nuff said.
*** That's when Trek actually crashed and they wisely decided to give everyone some time without a Trek series.
And to store all the solar energy one would have to pave the entire state of Arizona with batteries. Once they leak, everyone in New Mexico would die.
Even worse: Getting all the solar power from Japan to Arizona and back would incur huge losses so you'd need more solar power and batteries (you might need to pave over Arizona and Utah), not to mention thousands of miles of cables.
70% of the Anglosphere is using woot on a regular basis?
Anyway, descriptivists like to portray themselves as men of the people. "We just note the words, we don't prescribe them."
The problem with 100% descriptivism is that language is a social phenomenon. And when some comes to a place of work saying "ain't", he won't be lynched, but some people may view him as less educated.
Again, this is because language is a social phenomenon.
Any dictionary would be wise to note that certain words are view pejoratively by certain speakers.
But when you do that you lose the claim to purist descriptivism.
I was going to agree but while writing this post I've come to the conclusion that the proper answer is "that depends".
Most dictionaries do note where a word is appropriate, using tags like "colloquial", "pejorative" or "technical". That looks like prescription at first but can actually be purely descriptive. Noting that the definition "temporary data store" for "buffer" only applies in the context of computing does not make any statement about where it should be used; it describes where it will be understood that way.
Likewise, differentiating between "nut" as "a perforated block of metal with an internal screw thread" and as "a testis" is made easier by annotating them with contextual information. Now, this is where it gets interesting. The first meaning could be annotated with words like "technical" or "engineering" while staying purely descriptive but the annotation for the second meaning can have a varying degree of prescription. I'd put "colloquial" as a rather descriptive... description (as use of that meaning does happen mainly in colloqial contexts) while, for instance, Merriam-Webster use "usually vulgar", which gives us more social information but can also be seen a prescribing a reaction. Of course "vulgar" or even "offensive" would be even more prescriptive.
Now, the question is: How much do I prescribe? Do I just give a list of possible meanings without any further metadata about them so as to best avoid influencing common use? Do I add basic contextual information that is intended as a pure description of where a meaning is commonly used? That approach does have the advantage of making homonyms easier to distinguish. Do I explicitly note when a word might be considered inappropriate? That might help someone avoid a faux-pas but it does involve defining "bad" words or meanings, even though my work is inclusive of commonly-used words.
I'm not a lexicographer* but I'd say that basic contextual information like "this meaning is usually used in a botanics context" is part of a meaning and does not make your dictionary prescriptive. Of course even if it does the usual white-black analogy applies: Taking a hardline stance is unlikely to yield the best result and a descriptivist dictionary can afford to have a little bit of prescription in it. And the hardliners can take their opinion and shove it (as described by the Cambridge Advanced Learner's Dictionary).
* But as a nerd I can pointlessly argue about semantics for hours.
Borderlands does a lot better about it. I can put that down for a month, come back, read the mission descriptions that actually carry some fucking backstory, and get back into my character easier.
Exactly. One of the things that are awesome about Borderlands is the fact that you can easily pick it up, play it for a dozen hours or two and then put it down for a few months again. Granted, Diablo clones tend to have that quality (and Borderlands does borrow form Diablo quite a bit) but it's still an important quality for a game to have. If you want replay value, that is.
In fact, many of my favourite games are like that. Borderlands. Diablo 2 (naturally). Any of the first three X-Com games (just check up on your bases and soldiers and off you go). Minecraft.
One thing to note is that these games are either light on the story or make it easy to quickly see where you are. You can't make an ultra-cinematic game and have it work like this, at least not without the player losing a good bit of immersion when they come back. But if your game can afford to put the relevant parts of the story at the player's fingertips, doing so will increase its replay value in the sense of someone finishing a previously abandoned game.
Not that unfinished games can't still be awesome. I never finished Morrowind. That won't keep me from dumping dozens of hours into yet another character, though. And another one down the road. Sometimes a hundred hours of fun without closure can be better than twenty hours of fun with a nice ending.
You don't have to accomodate IE6? Lucky you. At my job, we make websites for businesses. Of course "working well in IE6" is still a core requirement. I guess we'll see the end of IE6 as mission-critical software not before Windows XP dies out far enough to not matter anymore. Given the fact that there are still businesses happily using Windows 9x I'd say that web design-wise 1998 will end somewhere in the 2030s.
When a browser adds a new CSS property, for example box-shadow, the property is added with a vendor prefix to denote that what the browser currently supports is the current snapshot of what the development team thinks the property should work like. Now, the dev team might be wrong or they might be conding against a feature that hasn't yet been finished. These things happen.
If nobody used vendor prefixes it'd be 1998 all over again: Web designers would need to find parsing hacks to exploit so they could make sure that each browser only acts on that one implementation of box-shadow that conforms to the way the browser works. We can't expect browser vendors to get their implementation 100% correct on the first try so saying that they should only make the property available once it works right is not a solution. Plus, it would mean that nobody could try to implement parts of the spec that haven't been set into stone yet, which would make it harder to find problems with the spec.
The nice thing about vendor prefixes is that they are self-disabling. If the real prefix has already been formalized you can write something like this:
/* Microsoft preliminary implementation - color attribute is ignored */ -ms-box-foo: 1px 1px 2px 2px red;
/* WebKit preliminary implementation - sizes switched around */ /* This was how the first draft specified it */ -webkit-box-foo: 2px 2px 1px 1px red;
/* Standard implementation */ box-foo: 1px 1px 2px 2px red }
While a browser only has preliminary support, that browser wil use the prefixed version of the property. Since the non-prefixed version comes last, however, it overrides the preliminary version if the browser supports it. Even if the preliminary implementations have quirks that persist, once the standard way is supported the browser will support it in the standard way. Thus, as soon as a browser has a conforming implementation, it will supersede the perliminary one since it was defined last. The designer needs to do no work whatsoever to make th new version of the browser behave correctly.
It's true that having browser-specific code is ugly but given the way web standards work it's really the best way we have to avoid much uglier hacks.
"Why should I compile for ARM? I've never even heard of that. Everyone uses x86."
Unless NaCl used something like Apple-style fat binaries that are guaranteed to contain all supported architectures we'd see a lot of people who only compile for their own architecture or who only upload those files they deem relevant.
Of course now Google wants to add functionality to let people distribute their code as LLVM bytecode that the browser has to compile. That does eat into the benefits of NaCL a bit; after all, having to first compile the code for the local platform requires more time and power than just loading a library. Plus, the question is whether current non-bytecode NaCL will be deprecated or if we will have to put up with "best viewed on x86" for a while. But it's still better than forcing web developers to think about how to cross-compile their code for random architectures.
a) drinking the red herring of realism Kool-Aid without understanding what games (and game design) are about.
b) It is easier to model reality, then engage your imagination and creativity -- there is a topic in game design what I call "Frame of Reference", but that is a topic for another day. If you are interested, I'll post a follow-up.
Consider me interested.
Oh, and I entirely agree with your post. I value consistency highly in video games and not just in the gameplay sense. I think that graphically, 3D games are just getting to the point where they might start looking as good as 2D games mainly because of consistency issues. I find many 3D games, especially newer ones, somewhat jarring because on one hand they have highly detailed surroundings and characters with plausible-looking skin and what not and on the other hand they use special effects that aren't nearly as lifelike - for example non-volumetric smoke. It was more jarring to see a puff of smoke halfway clip through a wall in, say, F.E.A.R. (where I really noticed it) than in Unreal because the former looked much more realistic otherwise. In 2D games such issues are more easily ignored since the graphics don't even pretend to be lifelike.
Consistency applies to many aspects of a game and it's fairly hard to get right. Graphical consistency can run into machine limitations - we can easily apply huge textures with displacement maps but volumetric smoke or plausible refractions are more expensive. Gameplay consistency requires you to think about things that ordinarily wouldn't even be design decisions and may require you to scrap mechanics that are cool but don't quite fit in. Of course some developers cut corners and go for "good enough" - after all, it's good enough. But excellency does require extra work.
Oh, I do. At my company we just had a talk with the boss about lack of management and its effects on us. Essentially we have him (who has no technical expertise and runs us as a side business), his second-in-command (who mostly handles customer relations) and two developers. Since nobody is there to translate between us the requirements often come across mangled and we were all surprised when it turned out that the developers interpreted silence as "nothing happened, I'm still working" while the others interpreted silence as "all work is done".
One of the effects of these communication issues is that most code I have written since joining the company needs a major overhaul despite not being that bad. It just either solves the wrong problem or solves the right problem in the wrong way.
We won't get a dedicated project manager but at least we talked the boss into getting a bit of process into the company. And I learned how useful it can be to have someone who speaks both developerese and nontechnicalese.
Well, in that case we just substitute "article" with "summary" in my post and stop wondering about whether the author has any idea of what they're writing about...
The KGB doesn't exist anymore. Russian intelligence agencies do exist but the KGB doesn't. You'd think that someone who remotely knows what they're talking about wouldn't end up writing an article about whether a long-defunct intelligence agency could infiltrate a defunct hacktivist group.
Had the question been "Could the SVR infiltrate Anonymous?" or "Could the SVR infiltrate LulzRaft?" the article might not immediately look like a bad rehash of a 1980s spy novel. But I guess "LulzSec" and "KGB" are more evocative and thus more suitable for swaying people who have no knowledge of intelligence services or computer security.
The punchline is "stay the fuck away from US-based services if you do anything with them that might be considered a threat to the bottom line of a corporation with a presence in America". They can already drag you to a kangaroo court* for possible infringement of laws you're not subject to; it's just a matter of time until they manage to find a way to wrap up random competitors in multi-year, multi-million dollar lawsuits that leave even a winning defendant crippled.
If you want to deal with America you either keep a low profile and hope not to anger anyone with deep pockets or you have the money and connections to pay the right people (not neccessarily politicians; for instance a well-timed media outrage might cause the plaintiff to back off).
* If every second US government agency seems already happy to do anyhing the corps say I wouldn't trust in the juciciary branch staying untainted for long. Besides, American laws are malleable if you have enough money so no, I don't think that you can expect a trial considered sane by anyone but corporate lawyers or politicians.
We don't see the comet itself in the video, just its tail. I'd imagine that the comet would produce a rather large tail close to the sun due to violent outgassing, plus comet comas/tails tend to be much larger than the comet itself (notably, in 2007 17P/Holmes briefly had a coma that appeared to be larger than the sun, with an actual diameter larger than the distance between Earth and the Moon; the comet itself was nowhere near as large as that).
Wouldn't the logical conclusion be to kick the arms manufacturers out (setting up government-owned entities to develop and produce equipment)? Of course that runs counter to principles like "the market will solve everything", "politicians love pork" and "the arms manufacturers have deep pockets" so it's both unpopular and unrealistic.
Slashdot Mirror
It has already been pointed out that HTML did evolve a lot. I'd like to add that the ecosystem it's part of has also evolved.
HTML 4 as written in 2011 is vastly different from HTML 4 written in 1997 (for instance, we tend not to write our sites for a specific version of a specific browser anymore). CSS as written in 2011 is vastly different from CSS written in 1996; for instance, before we had vendor prefixes we had to use hacks to present different CSS depending on browser and sometimes browser version. XHTML hasn't changed any since XHTML 1.0 but that's because XHTML 1.1 is so problematic to use that nobody uses it. JavaScript changed a lot in the last few years; I can still remember a time when using JS for anything important was a big no-no while today relying on JS isn't even neccessarily a barrier to a barrier-free site.
Nowadays web development even includes using technology that isn't widely supported yet - the magic of polyfills (another very young term) allows me to write a site that uses HTML5 features and still works on browsers that have no concept of HTML5. A few years ago any manipulation of the DOM was done by hand-written JS; today we ask Google for an instance of jQuery and use that.
Yes, I'm still using HTML 4.01, just like in 1999. But I'm no longer putting noise into my stylesheets to trigger IE parser bugs. I'm no longer limited to one-bit transparency because IE6 doesn't understand PNG alpha channels. I don't have to worry about whether an element has layout. And, quite frankly, if I wrote things like <script language="javascript"> today nobody would take me seriously as a web developer.
Saying that tech skills never age because languages stick around is like saying that the operating system as a concept is dead - after all, the market is utterly dominated by Windows and Unix, which have been around since 1981 and 1969, respectively. You'd think that they'd have come up with something new in the last thirty years.
There is a market for people who know old (versions of) languages but it's not identical with the market for people who know the current state of the art.
Well, I did start my sentence with "and if you don't go the C compatibility route", so we already were in a situation where "do like C does" is not an option.
Just for the record, I use "if (foo)" a lot and I like the construct. I don't use it a lot for comparisons against zero (false and null being much more common) but I can see how allowing zero in is a useful bit of syntactic sugar.
And if you don't go the C compatibility route, wouldn't it make more sense to throw an exception when trying to treat a non-boolean like a boolean instead of saying "everything but boolean true is false"?
Anyway, I just googled it and it appears that this behavior has been accepted as a bug. Well, partially. If the bug is fixed as requested in the bug report, everything will default to true now, with only null and false being false.
Then again, the setup time for a mail filter is less than a minute and it allows implicit searches, such as "What were the last five invoices sent to me by PayPal?". With a search function you need to look up which address PayPal uses to send invoices and then search for that. (Depending on which kind of mails you send/receive, just searching for "PayPal" might generate too many false matches.) With a folder fed by a filter tuned to that address you need one click. Oh, and once the filter is in place, having all existing matching mails categorized by it just requires running it on your inbox once.
/. mails can't crowd out more important mails. Filing always happens by filter; I never move mails by hand. Secondly they are mutually-exclusive search optimizations; a few searches are greatly simplified by having all mails on a particular topic pre-grouped.
To me, folders are two things: Firstly they are a way of visualizing metadata about my mails. Mails from my workplace have a higher priority than mails from Slashdot; having them filed at retrieval means that even a deluge of
Of course all of this does nothing to keep me from using searches, which I do. Thunderbird constructs a fulltext index so I can always search across all folders without losing performance or I can filter inside a folder. Folders and the search function are tools with different capabilities and purposes; there's some overlap but even there they are hardly mutually exclusive.
Now, I can understand the argument against manually-maintained folders. That takes time for every mail and most likely doesn't do anything a filter couldn't do better.
You said "tl;dr", but then posted something 5x as long.
I followed the "tl;dr" with a colon followed by a very brief version of my post. You may not be aware of it but "tl;dr:" is a converntion used to denote that a heavily abbreviated version of the post follows, used to preempt such statements. I admit that most people use it at the end of their posts, not the beginning, but I wanted to make clear right away what my post was supposed to express.
Power plants are "terminal" storage sites. As demonstrated at Fukushima, where they stored far more waste than fuel. As at practically every reactor in the US, and probably elsewhere. After a half century, it's obvious that's how we do it. Any other "plans" are science fiction or worse.
Still, most nuclear power plants are not entirely surrounded by rock. The post you replied to explicitly talked about underground storage sites. It does not matter whether these are currently used or even close; your reply does not work as you implicitly assumed that all storage sites are power plants in the context of a discussion about sites that aren't.
You could have replied with what you just wrote: That practical underground storage is nowhere near widespread implementation. That would have been a valid reply and could have been used as a bridge to the arguments you did make. Instead you argued that underground storage can't be safe because power plants can explode.
Again: My argument is not about the safety of nuclear power plants or current waste storage practices. It's about the semantics of your argument. Your argument was not wrong, it was used in a context where it didn't make sense because you didn't explain a premise you introduced.
Your sarcasm was inane, talking like Fukushima's waste storage was a unique situation. The fact is that waste is stored onsite. Then the site does get damaged, as Fukushima has most recently and undeniably demonstrated, and the radiation moves more than the few inches the earlier post tried to assure us was the safe and sound case.
We had a post talking about how proposed permanent underground storage facilities are a bad idea. Then we had a reply to that asserting that in these underground facilities the nuclear waste won't go anywhere, unlike CO2. Then you replied to that with a post based on what happened when a nucelar power plant exploded.
It doesn't matter how close we are to storing nuclear waste underground, the discussion was about the behavior of nuclear waste when stored underground, not about current waste storage practices.
You'd 'assume that "an explosion or fire disperses the waste over a large area" is a rather unlikely scenario.' even though it's eventual certainty was just proven at Fukushima.
I also made certain to point out that I was talking about underground storage facilities, nut power plants.
You haven't even bothered to acknowledge that in my last post I set you straight on the most basic reading comprehension.
No, you just unilaterally decided that the discussion was about something nobody else thought it was, then were surprised when people were talking about underground storage facilities and not power plants. You only introduced your premise that all storage facilities are power plants in your last post.
You are full of shit. Why should I care about your concern that in the long term people might not accept my arguments, when your reasons for doing so are that you're full of shit?
You're a crackpot, or worse. Since you won't shut up, I'm not giving you an excuse for posting more bullshit. Goodbye.
I'm sorry you feel that way.
Even after seeing the undeniable evidence you weren't aware that's what they do?
I saw undeniable evidence for them storing nuclear waste onsite. I never saw any evidence for any plans to never move that waste anywhere else, as the term "permanent storage" would imply. Now, most waste does only get shuffled around to temporary storage sites because it turns out that speccing out a permanent facility is really hard and takes ages. But that doesn't mean that any given NPP qualifies as a terminal storage site.
They also like to store nuke waste in nuke plants that get hit by earthquakes. You probably missed that in Virginia last month, too. And the one in Nebraska that the month before was a few inches from being flooded and facing the same pump failures that widely dispersed nuke waste in Japan.
The meltdown didn't cause widespread dispersal of the nuke waste in Fukushima. It was the explosion and fires. But so what? Each reactor is different, each has a variety of threats, and already several this year in the US have come within reach of what we saw in Fukushima just a little earlier. All of which have a terrible cost when those risks finally materialize, as we see in these plants that have been corruptly extended far beyond their designed or originally permitted operating lifetime.
You keep supplying arguments for an entirely different argument (safety of nuclear power plants) while trying to argue about the safety of terminal nuclear waste storage facilities.
I don't doubt that NPPs have issues, especially older ones that should be replaced. We are arguing, however, about whether nuclear waste stored in a terminal storage site has the potential of irradiating more than just its immediate vincinity. Which I also never called into question.
Given that terminal storage site plans usually call for the waste to be stored under conditions that make a runaway reaction extremely unlikely or impossible and for no volatile compounds or machinery to be near the waste and that the whole facility is underground, I'd assume that "an explosion or fire disperses the waste over a large area" is a rather unlikely scenario. Likewise, just about all scenarios relevant to NPPs are irrelevant here because NPPs behave fundamentally different to terminal storage sites.
There are other scenarios that we need to worry about, such as rain seeping through the facility and carrying some of the waste into the ground water. Trying to argue that since NPPs can explode, so can any other facility involving nuclear fuel is useless - it's like arguing that there is a significant risk of traffic accidents inside a car factory because there's a lot of cars there. That doesn't mean I'm arguing that car factories and highways are harmless; I'm arguing that car factories are dangerous in a different way and highways are not car factories.
But the risks, however real, are not what I was talking about. I was debunking the other lie about how nuke waste is dangerous only within a few inches. Which Fukushima just demonstrated, and intolerable cost, is just a lie. Now you're moving the goalposts, another favorite fallacy you nuke fetishists favor.
No, you just apparently misunderstood the GPP. The GPP's post talked about how nuclear waste behaves when underground, as made obvious by the statement that the radiation only "radiates a few centimetres in the rock". The statement made was that nuclear waste is solid and will not move much when the conditions of its storage facility change slightly. CO2, being a gas, will immediately seep out if a crack forms.
Now, there are valid arguments against that. For instance, water is not solid, will happily seep through any cracks that form and will erode the containers until
I wasn't aware that the preferred means of permanently storing nuclear waste was to have a tsunami hit a badly-maintained nuclear power plant. (I am aware that NPPs store some waste onsite but that's neither intended not in any way related to permanent storage plans.)
Most or all permanent nuclear storage facilities have flaws but the possibility of a meltdown causing widespread dispersal is not one of them. Whether your point is valid or not, using badly-researched arguments to make it will make you look like a crackpot.
Admittedly, the prequel trilogy did a lot to point out that George Lucas can be silly, too. I was thinking back to the Nineties when Star Wars was still respected and George Lucas was seen as a decent filmmaker.
From the prespective of someone who only became aware of Trek when TNG rolled around, things are a bit different.
Wars is the serious, mature one. It's about a war, with all that entails, which Trek only got close to during DS9 (which has a rather mixed reputation due to its darker tone). Trek has always been a wacky trip through the galaxy and when something nasty shows up it's usually resolved or postponed at the end of the episode.
Plus, Wars is the ultra-successful money-making machine while Trek is more of a reliable investment - Trek will have its series, which will always run seven seasons (excluding TOS*, TAS** and ENT***), and will also have a movie every now and then. Wars, meanwhile, has its movies, which are guaranteed to make tons of money, plus a bunch of other fluff.
Star Wars was even "around" before Trek. Star Wars came out in 1977 while the earliest bit of Trek us youngsters are usually exposed to is Star Trek: The Motion Picture from 1979. Yes, there was TOS, but most people only know it as meta-lore. In fact, what got most people my age (20-30) hooked on Trek wasn't the movies but TNG, which only appeared in 1987, well after the original Wars trilogy was done.
Plus, it's not like TOS was that successful. Granted, it lasted for three seasons but it was never a reliable ratings generator like TNG, DS9 and VOY.
* Like Firefly it generated most of its fame after its death.
** It's a Filmation spinoff series. 'nuff said.
*** That's when Trek actually crashed and they wisely decided to give everyone some time without a Trek series.
The description on YouTube says that it's the ionosphere. So unless we count the sun and its light as pollution I don't think that line qualifies.
And to store all the solar energy one would have to pave the entire state of Arizona with batteries. Once they leak, everyone in New Mexico would die.
Even worse: Getting all the solar power from Japan to Arizona and back would incur huge losses so you'd need more solar power and batteries (you might need to pave over Arizona and Utah), not to mention thousands of miles of cables.
70% of the Anglosphere is using woot on a regular basis?
Anyway, descriptivists like to portray themselves as men of the people. "We just note the words, we don't prescribe them."
The problem with 100% descriptivism is that language is a social phenomenon. And when some comes to a place of work saying "ain't", he won't be lynched, but some people may view him as less educated.
Again, this is because language is a social phenomenon.
Any dictionary would be wise to note that certain words are view pejoratively by certain speakers.
But when you do that you lose the claim to purist descriptivism.
I was going to agree but while writing this post I've come to the conclusion that the proper answer is "that depends".
Most dictionaries do note where a word is appropriate, using tags like "colloquial", "pejorative" or "technical". That looks like prescription at first but can actually be purely descriptive. Noting that the definition "temporary data store" for "buffer" only applies in the context of computing does not make any statement about where it should be used; it describes where it will be understood that way.
Likewise, differentiating between "nut" as "a perforated block of metal with an internal screw thread" and as "a testis" is made easier by annotating them with contextual information. Now, this is where it gets interesting. The first meaning could be annotated with words like "technical" or "engineering" while staying purely descriptive but the annotation for the second meaning can have a varying degree of prescription. I'd put "colloquial" as a rather descriptive... description (as use of that meaning does happen mainly in colloqial contexts) while, for instance, Merriam-Webster use "usually vulgar", which gives us more social information but can also be seen a prescribing a reaction. Of course "vulgar" or even "offensive" would be even more prescriptive.
Now, the question is: How much do I prescribe? Do I just give a list of possible meanings without any further metadata about them so as to best avoid influencing common use? Do I add basic contextual information that is intended as a pure description of where a meaning is commonly used? That approach does have the advantage of making homonyms easier to distinguish. Do I explicitly note when a word might be considered inappropriate? That might help someone avoid a faux-pas but it does involve defining "bad" words or meanings, even though my work is inclusive of commonly-used words.
I'm not a lexicographer* but I'd say that basic contextual information like "this meaning is usually used in a botanics context" is part of a meaning and does not make your dictionary prescriptive. Of course even if it does the usual white-black analogy applies: Taking a hardline stance is unlikely to yield the best result and a descriptivist dictionary can afford to have a little bit of prescription in it. And the hardliners can take their opinion and shove it (as described by the Cambridge Advanced Learner's Dictionary).
* But as a nerd I can pointlessly argue about semantics for hours.
Borderlands does a lot better about it. I can put that down for a month, come back, read the mission descriptions that actually carry some fucking backstory, and get back into my character easier.
Exactly. One of the things that are awesome about Borderlands is the fact that you can easily pick it up, play it for a dozen hours or two and then put it down for a few months again. Granted, Diablo clones tend to have that quality (and Borderlands does borrow form Diablo quite a bit) but it's still an important quality for a game to have. If you want replay value, that is.
In fact, many of my favourite games are like that. Borderlands. Diablo 2 (naturally). Any of the first three X-Com games (just check up on your bases and soldiers and off you go). Minecraft.
One thing to note is that these games are either light on the story or make it easy to quickly see where you are. You can't make an ultra-cinematic game and have it work like this, at least not without the player losing a good bit of immersion when they come back. But if your game can afford to put the relevant parts of the story at the player's fingertips, doing so will increase its replay value in the sense of someone finishing a previously abandoned game.
Not that unfinished games can't still be awesome. I never finished Morrowind. That won't keep me from dumping dozens of hours into yet another character, though. And another one down the road. Sometimes a hundred hours of fun without closure can be better than twenty hours of fun with a nice ending.
Because it's the leading actor, duh.
You don't have to accomodate IE6? Lucky you. At my job, we make websites for businesses. Of course "working well in IE6" is still a core requirement. I guess we'll see the end of IE6 as mission-critical software not before Windows XP dies out far enough to not matter anymore. Given the fact that there are still businesses happily using Windows 9x I'd say that web design-wise 1998 will end somewhere in the 2030s.
When a browser adds a new CSS property, for example box-shadow, the property is added with a vendor prefix to denote that what the browser currently supports is the current snapshot of what the development team thinks the property should work like. Now, the dev team might be wrong or they might be conding against a feature that hasn't yet been finished. These things happen.
If nobody used vendor prefixes it'd be 1998 all over again: Web designers would need to find parsing hacks to exploit so they could make sure that each browser only acts on that one implementation of box-shadow that conforms to the way the browser works. We can't expect browser vendors to get their implementation 100% correct on the first try so saying that they should only make the property available once it works right is not a solution. Plus, it would mean that nobody could try to implement parts of the spec that haven't been set into stone yet, which would make it harder to find problems with the spec.
The nice thing about vendor prefixes is that they are self-disabling. If the real prefix has already been formalized you can write something like this:
While a browser only has preliminary support, that browser wil use the prefixed version of the property. Since the non-prefixed version comes last, however, it overrides the preliminary version if the browser supports it. Even if the preliminary implementations have quirks that persist, once the standard way is supported the browser will support it in the standard way. Thus, as soon as a browser has a conforming implementation, it will supersede the perliminary one since it was defined last. The designer needs to do no work whatsoever to make th new version of the browser behave correctly.
It's true that having browser-specific code is ugly but given the way web standards work it's really the best way we have to avoid much uglier hacks.
"Why should I compile for ARM? I've never even heard of that. Everyone uses x86."
Unless NaCl used something like Apple-style fat binaries that are guaranteed to contain all supported architectures we'd see a lot of people who only compile for their own architecture or who only upload those files they deem relevant.
Of course now Google wants to add functionality to let people distribute their code as LLVM bytecode that the browser has to compile. That does eat into the benefits of NaCL a bit; after all, having to first compile the code for the local platform requires more time and power than just loading a library. Plus, the question is whether current non-bytecode NaCL will be deprecated or if we will have to put up with "best viewed on x86" for a while. But it's still better than forcing web developers to think about how to cross-compile their code for random architectures.
Perhaps the GP is thinking about Trident. That's entirely plausible if they have been in a coma for the last decade, for instance.
a) drinking the red herring of realism Kool-Aid without understanding what games (and game design) are about. b) It is easier to model reality, then engage your imagination and creativity -- there is a topic in game design what I call "Frame of Reference", but that is a topic for another day. If you are interested, I'll post a follow-up.
Consider me interested.
Oh, and I entirely agree with your post. I value consistency highly in video games and not just in the gameplay sense. I think that graphically, 3D games are just getting to the point where they might start looking as good as 2D games mainly because of consistency issues. I find many 3D games, especially newer ones, somewhat jarring because on one hand they have highly detailed surroundings and characters with plausible-looking skin and what not and on the other hand they use special effects that aren't nearly as lifelike - for example non-volumetric smoke. It was more jarring to see a puff of smoke halfway clip through a wall in, say, F.E.A.R. (where I really noticed it) than in Unreal because the former looked much more realistic otherwise. In 2D games such issues are more easily ignored since the graphics don't even pretend to be lifelike.
Consistency applies to many aspects of a game and it's fairly hard to get right. Graphical consistency can run into machine limitations - we can easily apply huge textures with displacement maps but volumetric smoke or plausible refractions are more expensive. Gameplay consistency requires you to think about things that ordinarily wouldn't even be design decisions and may require you to scrap mechanics that are cool but don't quite fit in. Of course some developers cut corners and go for "good enough" - after all, it's good enough. But excellency does require extra work.
Oh, I do. At my company we just had a talk with the boss about lack of management and its effects on us. Essentially we have him (who has no technical expertise and runs us as a side business), his second-in-command (who mostly handles customer relations) and two developers. Since nobody is there to translate between us the requirements often come across mangled and we were all surprised when it turned out that the developers interpreted silence as "nothing happened, I'm still working" while the others interpreted silence as "all work is done".
One of the effects of these communication issues is that most code I have written since joining the company needs a major overhaul despite not being that bad. It just either solves the wrong problem or solves the right problem in the wrong way.
We won't get a dedicated project manager but at least we talked the boss into getting a bit of process into the company. And I learned how useful it can be to have someone who speaks both developerese and nontechnicalese.
Well, in that case we just substitute "article" with "summary" in my post and stop wondering about whether the author has any idea of what they're writing about...
The KGB doesn't exist anymore. Russian intelligence agencies do exist but the KGB doesn't. You'd think that someone who remotely knows what they're talking about wouldn't end up writing an article about whether a long-defunct intelligence agency could infiltrate a defunct hacktivist group.
Had the question been "Could the SVR infiltrate Anonymous?" or "Could the SVR infiltrate LulzRaft?" the article might not immediately look like a bad rehash of a 1980s spy novel. But I guess "LulzSec" and "KGB" are more evocative and thus more suitable for swaying people who have no knowledge of intelligence services or computer security.
The punchline is "stay the fuck away from US-based services if you do anything with them that might be considered a threat to the bottom line of a corporation with a presence in America". They can already drag you to a kangaroo court* for possible infringement of laws you're not subject to; it's just a matter of time until they manage to find a way to wrap up random competitors in multi-year, multi-million dollar lawsuits that leave even a winning defendant crippled.
If you want to deal with America you either keep a low profile and hope not to anger anyone with deep pockets or you have the money and connections to pay the right people (not neccessarily politicians; for instance a well-timed media outrage might cause the plaintiff to back off).
* If every second US government agency seems already happy to do anyhing the corps say I wouldn't trust in the juciciary branch staying untainted for long. Besides, American laws are malleable if you have enough money so no, I don't think that you can expect a trial considered sane by anyone but corporate lawyers or politicians.
We don't see the comet itself in the video, just its tail. I'd imagine that the comet would produce a rather large tail close to the sun due to violent outgassing, plus comet comas/tails tend to be much larger than the comet itself (notably, in 2007 17P/Holmes briefly had a coma that appeared to be larger than the sun, with an actual diameter larger than the distance between Earth and the Moon; the comet itself was nowhere near as large as that).
Wouldn't the logical conclusion be to kick the arms manufacturers out (setting up government-owned entities to develop and produce equipment)? Of course that runs counter to principles like "the market will solve everything", "politicians love pork" and "the arms manufacturers have deep pockets" so it's both unpopular and unrealistic.