That's a great post, but while it's quite clear to me you think you were disagreeing with me somehow, I can't actually find the point of disagreement.
Perhaps you don't understand the "sort of" in "sort of used both"? Obviously it's a turn based system, duh. But it has a lot in common with the active time system, too, and tactically it's better understood as a frozen ATB system with no action delays than the older, simpler round-based systems; manipulating your opponents turn has no equivalent in those round-based systems and that's a qualitative difference.
There isn't the binary distinction you think there is; it's a continuum with the old-style "one-round, one-turn" system of yore near one end and the Grandia II-style system near the other (which actually takes the system a step further by adding positions in, although it sounds likely that FFXII will that too).
If I take all of their textures and pick-and-choose-and-cut-and-paste until I have something that looks like a boobie, did the software "ship" with that boobie?
Information theory to the rescue. In order to do that, your instructions will either be quite lengthy, or your search time will be long. Either way, the very instructions themselves constitute additional content; they are not themselves free of meaning or implication, as that would mean by definition they would have no effect.
You're still adding the "boobie" information to a product that did not previously contain it.
There is still a philosophical conundrum along the lines of "what, ultimately, does this long series of numbers really mean?", but this answer is sufficient to cover everything I've been able to think of from a legal standpoint. In my terms, no matter how tricky you get in the encoding, you're still adding the concrete part of the boobie.
FFX didn't use Active Time Battle, it used a turn based system...
It sort of used both. It used the same basic algorithm as the Active Time Battle, it's just that instead of rolling the clock along once your turn arrives, it stops and lets you select your action, and allows you to see the order of actions assuming all future turns are a basic attack.
With this system, you can actually see whether, for instance, your "delay attack" attack is worth firing, because when you point it at a monster you can see its turn being affected (assuming it connects, although in FF it pretty much always does during normal play). Sometimes it would delay the turn but it would still go before your characters anyhow, which you can see if you read the bars correctly.
It's not a straight turn-based system; this is why it's possible for one character to go twice in a row, for instance, or why every time your Summon fought another Summon, when you used your (forget the exact term) mega-attack you got whacked about three times in a row by the other summon before you got another turn.
Oh, come on, you're missing the first rule of Star Trek Military Technology, which is "All your opponents are complete idiots, so you can be too."
We're talking about a bunch of people who will beam into a highly volatile combat situation with a short-range low-powered raygun, or, if the situation is truly desparate, a medium-range low-powered raygun with effective ranges in the tens or hundreds of feet for all but the most expert users.
Grenades? Armor? Vehicles? Artillery of any kind, including simply "bigger weapons"? Sanity? Comprehension of tactics? All relics of a by-gone era.
Little fiddly details like the ones you're complaining about are all going to become increasingly irrelevant in the brave new era of strategy and tactics where the winner will be decided by whose plasma beam is prettier!
emacs used to be a heavy editor. But "heavy" is a relative term. In an era where people will open Eclipse to edit a file, is emacs really heavy anymore? Probably not. Most of the features people will complain about like news reader, etc., are loadable modules anyhow and who cares what modules the program might load?
On my personal system, emacs in text mode loads before I'm ready to edit the file, which is all I can ask for, and it's still the fastest XWindows editor I can open. It may be "heavier" than other editors based on GTK or QT, but it seems GTK and QT aren't necessarily "light" themselves, so my emacs will be up way before even lightweight things like GEdit.
I think calling emacs "heavy" now is just inertia from the era of 1MB machines. If emacs is heavy, than so is damn near every app I run and that's not a very useful definition if it never distinguishes between anything.
I don't know how they implemented this hybrid drive, and I don't know how much integration with the OS it does.
But I can say that if you did integrate with the OS, then you wouldn't necessarily need to cram all the system files into that space; you'd only need to cram all the system file pages that your system uses to boot. I have no idea how large this set is, except that it is bounded on the upper end by the total file size you thought would have to go in, but my intuition is that it's a lot smaller. (Windows "must" have IDE support in its system files to boot, but you wouldn't need the pages containing that code for a SCSI system.) I wouldn't be surprised either way that 256MB was sufficient.
In fact booting should already work this way in terms of what is actually read off of the disk (libraries are typically "mapped" and paged in, rather than being "loaded", for just this reason), so it's not even necessarily a lot of extra code, it's just that the hard drive would need to work with the system.
However, thinking about it this way points out a problem with the marketting spiel. The globally optimal behavior will be to treat it exactly as I highlight above; as basically another layer of swap between "in memory" and "on the physical hard disk", perhaps with a healthy dollop of space reserved for write-behind caching to catch the case where you save a file and don't want to spin up the harddrive for it. However, in that case, you'll want to use existing swap selection algorithms, which will eventually (and correctly!) flush the OS bits that aren't in continuous use out of the swap area. If you want to maintain those bits on purpose, you can special-case them in, but at the cost that you'll degrade the value of the flash memory whenever you aren't booting.
If we were talking 5GB of flash, I might be willing to make that trade, but at 256MB, I doubt I'd want to throw it away for that. Booting up may be annoying but it is still something you do fairly rarely.
Well, the more I think about it, the more interesting possibilities arise, but I gotta post this sometime. Anyhow, the upshot is that you definitely do not necessarily need to all of the files the OS uses to boot, just the bits it actually uses.
Re:Why not lock, instead of unlock?
on
Just Let Me Play!
·
· Score: 2, Interesting
It sounds like the upcoming Red Steel for the Wii has something like that, although the focus isn't on resource deprivation from the sounds of it so much as attaining greater elegance over time.
I expect this will bother a lot of people, that the perceived power level of the weapons will go down over time, but as the kind of person who had a hard time running anything other than a sniper through the Fallouts, I'm looking forward to it. Doing a lot with a little is more fun than spraying things down.
That said, I agree with the sibling post about ammo deprivation. I Code: Veronica for my Dreamcast and I'm glad I bought it used at $10, because I can't stand it. I think I'd have been ok with it if the movement scheme wasn't complete garbage (I don't give a rat's ass if it's "traditional", I've been gaming for over 20 years now and that's one of the least intuitive control schemes ever, completely wrecking the immersion), but combining that with ammo handed out begrudgingly was just too much. I don't mind hard games themselves, I've played a lot, but I hate it when I feel like the mechanics themselves are out to get me and half the challenge lies in a crappy control scheme.
Once I managed to toast my DDR save somehow, and wham-bang, most of my favorite songs are suddenly unavailable. Losing my grades I can deal with; those are pretty easily replaced. Losing the unlocked songs was a major PITA. (And in DDRMAX2, which is the game that I lost, the only, sole, and singular way to unlock the songs is to play through 300 stages, IIRC, a matter of weeks at any sane speed, even with my wife helping.)
Meanwhile, in DDRExtreme 2, which I've played a lot, I still don't even know how many songs there are that I paid for and can't play. My wife and I are "well above average" amoung "everybody who has ever played DDR", which is to say we can routinely get through Standard mode songs now, but by DDR standards we're still beginners. The unlockable technique is to play through various challenges, and we've pretty much gotten to the point where we can't progress any further, and I know there are more songs in there. It annoys me when I think about it.
(Besides, at 6'4", I've come to realize that I am rapidly approaching the point where it simply doesn't matter how much better my brain or my muscles get; I'm not certain I'm ever going to be physically capable of doing Heavy for most songs. I've just got too much leg to move around to do it as quickly as smaller people.)
The sibling post from cgenman points to the solution, I think; go ahead with your unlockable scheme, but provide unlocking codes for those of us who just want our songs, damn it, or lost our save file (which happens!). This probably applies more to Guitar Hero and DDR-type games than most.
I haven't found anything that is knock-down, drop-dead better. I've found lots of things that will be knock-down, drop-dead better someday, if the theories all work out, there aren't any implementation problems or unresolvable scaling issues, the devs don't get discouraged by the continuing dominance of Subversion, and they get more testing in larger environments.
And where I work, we do have a couple of truly large trees, that Subversion is just barely able to keep up with (some very recent improvements are helping), and from what I've gathered a lot of the theoretically better revision control systems all fare even worse. Except gits, which I gather basically sucks unless you have exactly the same situation as the Linux kernel, in which case it is God's gift to man. (Our situation is dissimilar to that in a number of ways.)
I have read the criticisms of subversion. It's better than CVS. I agree it's not perfect and still carries over some architectural decisions from CVS that are less than perfect. (And I rather wish they hadn't given up on the "plugins" idea as it would have saved me a lot of work twice now.) But it's here, now.
If you know of something else that gracefully handles tens of thousands of files w/ branching and stuff, I'm listening. (No sarcasm.)
I doubt I'll have much to add to the long list of people describing their experiences with various systems, but I'll pop out this meta-thought: Your developers and "functional analysts" probably have wildly varying needs, especially if the "functional analysts" use word-processing documents like Word. There's no crime in given each group of people a separate system.
Your devs probably ought to get subversion because the continuing cost of using a sub-optimal source management system adds up to staggering amounts pretty fast. Your other writers probably aren't continuously branching and merging and doing all the other things subversion allows (if nothing else that's really confusing for most documents), so they can use a simpler, easier-to-use system that doesn't incur continuous costs due to confusion and documents getting mangled or destroyed due to incorrect use of the system.
The right tool for the right job.
(Note: I'm not saying you should use multiple systems; I'm just saying it's not a crime, if they solve different problems. If you can get your writers to use SVN, especially if they use something with a decent plaintext representation that stands a chance in Hell of merging, hey, great, more power to you.)
Are you kidding? One of the primary problems with journalism right now is excessive agreement amoungst the journalists. It's a rare issue where you won't get at least 80% agreement right now, possibly more, on issues where the general public is substantially more split.
It is, slowly, getting better, but it sure is taking a long time, and I still couldn't hardly name a journalist that I'd call "libertarian". (John Stossel, maybe.) Even the diversity that is slowly developing is still on the right/left axis, and ignoring the others.
They say that high performers can keep telecommuting, but I somehow doubt they'll allow that due to morale issues.
This reminds me of an old Dilbert cartoon, where the PHB announces that the company will be cutting back on business card printing, and only vital employees will be allowed to order business cards. In the next panel, every employee is thinking "I'd better order business cards to find out if I'm 'vital'.".
I expect this would go the same way... well, actually the employees will jump to the correct conclusion that none of them are considered "high" enough "performers" to be worth extra benefits. (How mysterious.)
Of course, the management response to this problem, since of course we can't have some people being better than others at the same status level, is to finish completely eliminating telecommuting.
What gets me about the management blunders that everybody loves to hate is not that they occur; we blunder through a world complicated beyond our faintest ability to handle except rarely by accident, so stupid decisions are the norm. What gets me is, despite that, how predictable these management blunders are and just how poor the response is in general. The same problem is faced thousands of times a year, and almost everybody tasked with solving it will try the exact same (wrong) solution, because "more control" is always the answer (regardless of the competence of the "controllers", regardless of the effectiveness), and (the part that really boggles my mind) almost none of them will look around to see who else has tried that solution and what unanticipated consequences may arise, even though umpteen millions or billions of dollars may be at stake.
And nuance is something slashdot appears to be lacking these days.
Nuance is for people who aren't already absolutely, positively certain that they are 100% correct and anyone who disagrees in the slightest way is stupid. Also evil. Possibly eats babies.
Fixing "memory hogging" generally require significant architecture changes. This is not the sort of thing you get on a x.x.x.1 release.
I'm sure they're addressing this issue as it is easily now the #1 complaint about Mozilla. I recall it having memory issues even before plugins and the memory-hogging history-full-page-store feature (the one where you hit "back" and the page is just supposed to pop up, not re-render or re-request), but those two issues have magnified the issue into something that can't be ignored or poo-poo'ed anymore; I, too, will often see my Firefox hovering around the 600MB mark, and I recently installed that memory leak test tool and it didn't come up often at all.
Probably ought to shut off that feature; doesn't seem to do much for me anyhow.
Sorry, using DES has been not "correctly encrypted" for over a decade now. 3-DES wasn't pulled out of somebody's ass for no reason, and thats not trustworthy either.
Only in Hollywood can a brilliant physicist sit down and crack encryption in five or ten minutes, no matter how strong.
Out here in the real world, you're not going to crack correctly-applied encryption in your lifetime, even if your Bruce Scheier, the guy who wrote the book on encryption.
A lot of encryption is misapplied, but short of leaving the password on a post-it note on the machine, or leaving the machine on all the time, full-disk encryption is pretty easy-to-use.
Oh, good! My PS2-PC has been getting pretty slow browsing the web lately; the Flash really kills it, and of course there's no option to turn it off in the crappy browser it gives me.
(Translation: The "our console will also be a computer!" lie is older than quite a few of the people who will read this post, and older than many of the customers Sony is targetting. Believe it when you have the computer hardware and general-purpose, useful software in your hands and running in your living room and doing something useful, and not one second earlier.)
In summary: don't blame [language] for shitty programs, blame the programmer.
Every time I see this, I compile it to "Blame the programmer for picking a shitty language."
It hasn't failed me yet.
Some languages are worse than others. How do they accomplish this? They make it easier to do the wrong thing than the right thing. Better languages (and libraries, APIs, etc) make it easier to do the right thing than the wrong thing. Sometimes this makes them seem harder, because they have to discard the very easiest (but wrong) approach, but in the medium and long term, you're much better off.
Why can a programmer compensate for a bad language? In most languages, the programmer can do the right thing anyhow, even though it's harder. But generally only the very brightest can learn all of these "right things" while living in the bad environment; on average, you're going to have to pull this wisdom in from another, better environment. (And I've also seen cases where even people who think they've figured out the tricks still really haven't; they worked out something that sort of works, but only in their bad environment.)
The programmer may take some of the blame, but the language and environment of something like VB6 still gets a heaping helping of blame for enabling and encouraging short-sighted tradeoffs.
(And this analysis assumes the language is generally capable and bug free, something VB has trouble with on both counts, being buggy and requiring a lot of much harder work to access the trickier bits of even the Windows API, let alone external libraries. But this is just a side note.)
My templates are (I'm sure) parsed on each invocation though.
I'd be surprised. I know Apache::ASP compiles each web page ("template") down to a Perl subroutine once per execution (unless you change it); I'd bet the TT works the same way. The speed gains are too large to ignore, especially in a web environment, and Perl makes it too easy.
I don't know where they got the idea that all scripting languages must always parse the script on every invocation.
Some people have used that as part of the definition of "scripting language". Pre-dot-Net ASP* also worked that way, although I got out of that a long time before.Net and for all I know Microsoft shipped an accelerator at some point before.Net.
There was a time when this idea had at least some value. However, it's been a while now since I've heard a useful definition of "scripting language" beyond "what people have traditionally called scripting languages"; about the only criterion left is "statically typed" vs. "dynamically typed", and it's much more descriptive to actually use those terms instead of "scripting language" in that case.
(*: Which seems to be what PHP copied itself from, which actually explains a lot about PHP.)
"Over 400 puzzles"? I sure hope they mean "over 400 variants" of Sudoku or something. (Variants can add up fast when you have multiple independent dimensions to vary on; remember the old Atari 2600 games that had "32" variants, which were just all combinations of 5 binary flags? "Shots bounce" vs. "Shots don't bounce", for instance. Oh, and don't forget the color variations!)
Solving Sudoku puzzles is moderately computationally intensive and maybe the DS shouldn't be doing that, but it ought to be able to generate them just fine, and an experienced Sudoku player who is also a decent programmer even ought to be able to make a good stab at varying the difficulty levels automatically. (It doesn't have to be *perfect*, just mostly effective.)
Otherwise that's a bit of a rip-off; as long as you're going to computerize your Sudoku you might as well get all-the-puzzles-you-can-eat. (And for that matter, open the field up to some of the more advanced variants, like the 4-version.)
Slashdot Mirror
That's a great post, but while it's quite clear to me you think you were disagreeing with me somehow, I can't actually find the point of disagreement.
Perhaps you don't understand the "sort of" in "sort of used both"? Obviously it's a turn based system, duh. But it has a lot in common with the active time system, too, and tactically it's better understood as a frozen ATB system with no action delays than the older, simpler round-based systems; manipulating your opponents turn has no equivalent in those round-based systems and that's a qualitative difference.
There isn't the binary distinction you think there is; it's a continuum with the old-style "one-round, one-turn" system of yore near one end and the Grandia II-style system near the other (which actually takes the system a step further by adding positions in, although it sounds likely that FFXII will that too).
If I take all of their textures and pick-and-choose-and-cut-and-paste until I have something that looks like a boobie, did the software "ship" with that boobie?
Information theory to the rescue. In order to do that, your instructions will either be quite lengthy, or your search time will be long. Either way, the very instructions themselves constitute additional content; they are not themselves free of meaning or implication, as that would mean by definition they would have no effect.
You're still adding the "boobie" information to a product that did not previously contain it.
There is still a philosophical conundrum along the lines of "what, ultimately, does this long series of numbers really mean?", but this answer is sufficient to cover everything I've been able to think of from a legal standpoint. In my terms, no matter how tricky you get in the encoding, you're still adding the concrete part of the boobie.
FFX didn't use Active Time Battle, it used a turn based system...
It sort of used both. It used the same basic algorithm as the Active Time Battle, it's just that instead of rolling the clock along once your turn arrives, it stops and lets you select your action, and allows you to see the order of actions assuming all future turns are a basic attack.
With this system, you can actually see whether, for instance, your "delay attack" attack is worth firing, because when you point it at a monster you can see its turn being affected (assuming it connects, although in FF it pretty much always does during normal play). Sometimes it would delay the turn but it would still go before your characters anyhow, which you can see if you read the bars correctly.
It's not a straight turn-based system; this is why it's possible for one character to go twice in a row, for instance, or why every time your Summon fought another Summon, when you used your (forget the exact term) mega-attack you got whacked about three times in a row by the other summon before you got another turn.
Oh, come on, you're missing the first rule of Star Trek Military Technology, which is "All your opponents are complete idiots, so you can be too."
We're talking about a bunch of people who will beam into a highly volatile combat situation with a short-range low-powered raygun, or, if the situation is truly desparate, a medium-range low-powered raygun with effective ranges in the tens or hundreds of feet for all but the most expert users.
Grenades? Armor? Vehicles? Artillery of any kind, including simply "bigger weapons"? Sanity? Comprehension of tactics? All relics of a by-gone era.
Little fiddly details like the ones you're complaining about are all going to become increasingly irrelevant in the brave new era of strategy and tactics where the winner will be decided by whose plasma beam is prettier!
emacs used to be a heavy editor. But "heavy" is a relative term. In an era where people will open Eclipse to edit a file, is emacs really heavy anymore? Probably not. Most of the features people will complain about like news reader, etc., are loadable modules anyhow and who cares what modules the program might load?
On my personal system, emacs in text mode loads before I'm ready to edit the file, which is all I can ask for, and it's still the fastest XWindows editor I can open. It may be "heavier" than other editors based on GTK or QT, but it seems GTK and QT aren't necessarily "light" themselves, so my emacs will be up way before even lightweight things like GEdit.
I think calling emacs "heavy" now is just inertia from the era of 1MB machines. If emacs is heavy, than so is damn near every app I run and that's not a very useful definition if it never distinguishes between anything.
I don't know how they implemented this hybrid drive, and I don't know how much integration with the OS it does.
But I can say that if you did integrate with the OS, then you wouldn't necessarily need to cram all the system files into that space; you'd only need to cram all the system file pages that your system uses to boot. I have no idea how large this set is, except that it is bounded on the upper end by the total file size you thought would have to go in, but my intuition is that it's a lot smaller. (Windows "must" have IDE support in its system files to boot, but you wouldn't need the pages containing that code for a SCSI system.) I wouldn't be surprised either way that 256MB was sufficient.
In fact booting should already work this way in terms of what is actually read off of the disk (libraries are typically "mapped" and paged in, rather than being "loaded", for just this reason), so it's not even necessarily a lot of extra code, it's just that the hard drive would need to work with the system.
However, thinking about it this way points out a problem with the marketting spiel. The globally optimal behavior will be to treat it exactly as I highlight above; as basically another layer of swap between "in memory" and "on the physical hard disk", perhaps with a healthy dollop of space reserved for write-behind caching to catch the case where you save a file and don't want to spin up the harddrive for it. However, in that case, you'll want to use existing swap selection algorithms, which will eventually (and correctly!) flush the OS bits that aren't in continuous use out of the swap area. If you want to maintain those bits on purpose, you can special-case them in, but at the cost that you'll degrade the value of the flash memory whenever you aren't booting.
If we were talking 5GB of flash, I might be willing to make that trade, but at 256MB, I doubt I'd want to throw it away for that. Booting up may be annoying but it is still something you do fairly rarely.
Well, the more I think about it, the more interesting possibilities arise, but I gotta post this sometime. Anyhow, the upshot is that you definitely do not necessarily need to all of the files the OS uses to boot, just the bits it actually uses.
It sounds like the upcoming Red Steel for the Wii has something like that, although the focus isn't on resource deprivation from the sounds of it so much as attaining greater elegance over time.
I expect this will bother a lot of people, that the perceived power level of the weapons will go down over time, but as the kind of person who had a hard time running anything other than a sniper through the Fallouts, I'm looking forward to it. Doing a lot with a little is more fun than spraying things down.
That said, I agree with the sibling post about ammo deprivation. I Code: Veronica for my Dreamcast and I'm glad I bought it used at $10, because I can't stand it. I think I'd have been ok with it if the movement scheme wasn't complete garbage (I don't give a rat's ass if it's "traditional", I've been gaming for over 20 years now and that's one of the least intuitive control schemes ever, completely wrecking the immersion), but combining that with ammo handed out begrudgingly was just too much. I don't mind hard games themselves, I've played a lot, but I hate it when I feel like the mechanics themselves are out to get me and half the challenge lies in a crappy control scheme.
I also wish DDR had this option.
Once I managed to toast my DDR save somehow, and wham-bang, most of my favorite songs are suddenly unavailable. Losing my grades I can deal with; those are pretty easily replaced. Losing the unlocked songs was a major PITA. (And in DDRMAX2, which is the game that I lost, the only, sole, and singular way to unlock the songs is to play through 300 stages, IIRC, a matter of weeks at any sane speed, even with my wife helping.)
Meanwhile, in DDRExtreme 2, which I've played a lot, I still don't even know how many songs there are that I paid for and can't play. My wife and I are "well above average" amoung "everybody who has ever played DDR", which is to say we can routinely get through Standard mode songs now, but by DDR standards we're still beginners. The unlockable technique is to play through various challenges, and we've pretty much gotten to the point where we can't progress any further, and I know there are more songs in there. It annoys me when I think about it.
(Besides, at 6'4", I've come to realize that I am rapidly approaching the point where it simply doesn't matter how much better my brain or my muscles get; I'm not certain I'm ever going to be physically capable of doing Heavy for most songs. I've just got too much leg to move around to do it as quickly as smaller people.)
The sibling post from cgenman points to the solution, I think; go ahead with your unlockable scheme, but provide unlocking codes for those of us who just want our songs, damn it, or lost our save file (which happens!). This probably applies more to Guitar Hero and DDR-type games than most.
I haven't found anything that is knock-down, drop-dead better. I've found lots of things that will be knock-down, drop-dead better someday, if the theories all work out, there aren't any implementation problems or unresolvable scaling issues, the devs don't get discouraged by the continuing dominance of Subversion, and they get more testing in larger environments.
And where I work, we do have a couple of truly large trees, that Subversion is just barely able to keep up with (some very recent improvements are helping), and from what I've gathered a lot of the theoretically better revision control systems all fare even worse. Except gits, which I gather basically sucks unless you have exactly the same situation as the Linux kernel, in which case it is God's gift to man. (Our situation is dissimilar to that in a number of ways.)
I have read the criticisms of subversion. It's better than CVS. I agree it's not perfect and still carries over some architectural decisions from CVS that are less than perfect. (And I rather wish they hadn't given up on the "plugins" idea as it would have saved me a lot of work twice now.) But it's here, now.
If you know of something else that gracefully handles tens of thousands of files w/ branching and stuff, I'm listening. (No sarcasm.)
I doubt I'll have much to add to the long list of people describing their experiences with various systems, but I'll pop out this meta-thought: Your developers and "functional analysts" probably have wildly varying needs, especially if the "functional analysts" use word-processing documents like Word. There's no crime in given each group of people a separate system.
Your devs probably ought to get subversion because the continuing cost of using a sub-optimal source management system adds up to staggering amounts pretty fast. Your other writers probably aren't continuously branching and merging and doing all the other things subversion allows (if nothing else that's really confusing for most documents), so they can use a simpler, easier-to-use system that doesn't incur continuous costs due to confusion and documents getting mangled or destroyed due to incorrect use of the system.
The right tool for the right job.
(Note: I'm not saying you should use multiple systems; I'm just saying it's not a crime, if they solve different problems. If you can get your writers to use SVN, especially if they use something with a decent plaintext representation that stands a chance in Hell of merging, hey, great, more power to you.)
Agreement? Among journalists? Yeah, right.
Are you kidding? One of the primary problems with journalism right now is excessive agreement amoungst the journalists. It's a rare issue where you won't get at least 80% agreement right now, possibly more, on issues where the general public is substantially more split.
It is, slowly, getting better, but it sure is taking a long time, and I still couldn't hardly name a journalist that I'd call "libertarian". (John Stossel, maybe.) Even the diversity that is slowly developing is still on the right/left axis, and ignoring the others.
They say that high performers can keep telecommuting, but I somehow doubt they'll allow that due to morale issues.
This reminds me of an old Dilbert cartoon, where the PHB announces that the company will be cutting back on business card printing, and only vital employees will be allowed to order business cards. In the next panel, every employee is thinking "I'd better order business cards to find out if I'm 'vital'.".
I expect this would go the same way... well, actually the employees will jump to the correct conclusion that none of them are considered "high" enough "performers" to be worth extra benefits. (How mysterious.)
Of course, the management response to this problem, since of course we can't have some people being better than others at the same status level, is to finish completely eliminating telecommuting.
What gets me about the management blunders that everybody loves to hate is not that they occur; we blunder through a world complicated beyond our faintest ability to handle except rarely by accident, so stupid decisions are the norm. What gets me is, despite that, how predictable these management blunders are and just how poor the response is in general. The same problem is faced thousands of times a year, and almost everybody tasked with solving it will try the exact same (wrong) solution, because "more control" is always the answer (regardless of the competence of the "controllers", regardless of the effectiveness), and (the part that really boggles my mind) almost none of them will look around to see who else has tried that solution and what unanticipated consequences may arise, even though umpteen millions or billions of dollars may be at stake.
And nuance is something slashdot appears to be lacking these days.
Nuance is for people who aren't already absolutely, positively certain that they are 100% correct and anyone who disagrees in the slightest way is stupid. Also evil. Possibly eats babies.
Yup, I totally agree that slime that seems to be able to replicate itself could eventually develop into something that could replace us.
However, history indicates that the time required will be somewhere around 500 million to two billion years, depending on where you draw the line.
This is not something that keeps me up at night.
Fixing "memory hogging" generally require significant architecture changes. This is not the sort of thing you get on a x.x.x.1 release.
I'm sure they're addressing this issue as it is easily now the #1 complaint about Mozilla. I recall it having memory issues even before plugins and the memory-hogging history-full-page-store feature (the one where you hit "back" and the page is just supposed to pop up, not re-render or re-request), but those two issues have magnified the issue into something that can't be ignored or poo-poo'ed anymore; I, too, will often see my Firefox hovering around the 600MB mark, and I recently installed that memory leak test tool and it didn't come up often at all.
Probably ought to shut off that feature; doesn't seem to do much for me anyhow.
Sorry, using DES has been not "correctly encrypted" for over a decade now. 3-DES wasn't pulled out of somebody's ass for no reason, and thats not trustworthy either.
Only in Hollywood can a brilliant physicist sit down and crack encryption in five or ten minutes, no matter how strong.
Out here in the real world, you're not going to crack correctly-applied encryption in your lifetime, even if your Bruce Scheier, the guy who wrote the book on encryption.
A lot of encryption is misapplied, but short of leaving the password on a post-it note on the machine, or leaving the machine on all the time, full-disk encryption is pretty easy-to-use.
Oh, good! My PS2-PC has been getting pretty slow browsing the web lately; the Flash really kills it, and of course there's no option to turn it off in the crappy browser it gives me.
Still, it's a distinct step up from my Family Computer.
And the less said about my Entertainment Computer System, the better.
(Translation: The "our console will also be a computer!" lie is older than quite a few of the people who will read this post, and older than many of the customers Sony is targetting. Believe it when you have the computer hardware and general-purpose, useful software in your hands and running in your living room and doing something useful, and not one second earlier.)
Is there an "orangutan" player class?
Being a Librarian can be very dangerous in a world of magic. In the immortal word of one victim, "Ook!"
In summary: don't blame [language] for shitty programs, blame the programmer.
Every time I see this, I compile it to "Blame the programmer for picking a shitty language."
It hasn't failed me yet.
Some languages are worse than others. How do they accomplish this? They make it easier to do the wrong thing than the right thing. Better languages (and libraries, APIs, etc) make it easier to do the right thing than the wrong thing. Sometimes this makes them seem harder, because they have to discard the very easiest (but wrong) approach, but in the medium and long term, you're much better off.
Why can a programmer compensate for a bad language? In most languages, the programmer can do the right thing anyhow, even though it's harder. But generally only the very brightest can learn all of these "right things" while living in the bad environment; on average, you're going to have to pull this wisdom in from another, better environment. (And I've also seen cases where even people who think they've figured out the tricks still really haven't; they worked out something that sort of works, but only in their bad environment.)
The programmer may take some of the blame, but the language and environment of something like VB6 still gets a heaping helping of blame for enabling and encouraging short-sighted tradeoffs.
(And this analysis assumes the language is generally capable and bug free, something VB has trouble with on both counts, being buggy and requiring a lot of much harder work to access the trickier bits of even the Windows API, let alone external libraries. But this is just a side note.)
My templates are (I'm sure) parsed on each invocation though.
I'd be surprised. I know Apache::ASP compiles each web page ("template") down to a Perl subroutine once per execution (unless you change it); I'd bet the TT works the same way. The speed gains are too large to ignore, especially in a web environment, and Perl makes it too easy.
I don't know where they got the idea that all scripting languages must always parse the script on every invocation.
.Net and for all I know Microsoft shipped an accelerator at some point before .Net.
Some people have used that as part of the definition of "scripting language". Pre-dot-Net ASP* also worked that way, although I got out of that a long time before
There was a time when this idea had at least some value. However, it's been a while now since I've heard a useful definition of "scripting language" beyond "what people have traditionally called scripting languages"; about the only criterion left is "statically typed" vs. "dynamically typed", and it's much more descriptive to actually use those terms instead of "scripting language" in that case.
(*: Which seems to be what PHP copied itself from, which actually explains a lot about PHP.)
"Over 400 puzzles"? I sure hope they mean "over 400 variants" of Sudoku or something. (Variants can add up fast when you have multiple independent dimensions to vary on; remember the old Atari 2600 games that had "32" variants, which were just all combinations of 5 binary flags? "Shots bounce" vs. "Shots don't bounce", for instance. Oh, and don't forget the color variations!)
Solving Sudoku puzzles is moderately computationally intensive and maybe the DS shouldn't be doing that, but it ought to be able to generate them just fine, and an experienced Sudoku player who is also a decent programmer even ought to be able to make a good stab at varying the difficulty levels automatically. (It doesn't have to be *perfect*, just mostly effective.)
Otherwise that's a bit of a rip-off; as long as you're going to computerize your Sudoku you might as well get all-the-puzzles-you-can-eat. (And for that matter, open the field up to some of the more advanced variants, like the 4-version.)
xmtrx.GeekPoints--;
I'm pretty sure a Matrix hacking game would concentrate on buffer overflows.
There's one of those "nerd rock" songs in there with just a bit of editing...