Remember that for broadcast TV (in the US at least), you're not the customer, you're the product. Advertisers are the customers. Google can make money off TV advertising the same way they do everywhere else: by making ads more successful and therefore more profitable for advertisers. That lets networks charge more for advertising space and time, and Google takes a cut of that. The profit isn't in owning the pipes, it's in owning the eyeballs.
There's also the synergy angle, i.e. Google can tightly couple TV advertising with Web advertising. "Joe just saw an ad on TV for X and started Googling for information on it five minutes later, so let's show him ads for stores in the area which sell X." Going back to what I said before, with regards to Web advertising, Google pretty much owns all the eyeballs, so this has the potential to be really profitable for them.
or are you simply making a rather pathetic attempt at astroturfing for the meat industry that doesn't want people to be able to discriminate against whatever makes the industry more profits ?
Wow. I am not, nor have I ever been, an employee of the meat industry, or any other food-related industry. My sole association with them is eating some of their products. Seriously, tinfoil hat much? The mere fact that someone disagrees with you doesn't mean your opponent's taking bribes.
Whether histerical or not, whether dangerous or not, I am for TRUTH in labelling.
So am I, but truth doesn't imply completeness. The line needs to be drawn somewhere. That cow you want to eat may have ingested some kind of poison which suffused every cell of its body, and by eating it you could die. So it seems relevant, except that every slice of roast beef would have to include a 5000-page manual. At a certain point, we have to trust that the experts (that would be the FDA and other organizations) are, in fact, experts.
So considering that the overwhelming preponderance of scientific opinion on the matter is that these things are, in fact, perfectly safe (and safer than eating bacteria), it's perfectly rational and correct for the "default" case to be "virus included."
But not to worry. I'm sure someone is already out there forming a company to sell "Organic Lunchmeats" with all the original bacteria intact. With truth in labeling the virus-adding players won't be able to make the same claim, so you'll be able to tell the sides apart that way. Just like when you're buying pesticide-free food, non-GM food (in the US), rBGH-free dairy products, etc. Since you're probably the sort of person who buys all those things anyway, it will probably be more convenient for you too: just buy everything that says "Organic" or "All-Natural" on the label!
Agreed, but bear in mind that a single-bit error doesn't have to crash your system (or an app). In fact, it usually won't, because the amount of "critical" memory is very small relative to the total amount of RAM installed. Instead it will silently corrupt data. This could result in a momentary glitch in what's shown on the screen; it could result in an app delivering nonsensical results; or, far worse, it could result in bad data being written to disk or an app delivering subtly wrong results. Since all modern operating systems use all memory in your box for something (cache, usually) pretty much every single-bit error is going to screw something up.
I work with many ECC-using servers and there are typically one to five single-bit errors per month. Even though I understand the reasons for it, I am kind of bewildered that ECC isn't more common on high-end desktop systems. The RAM costs ~15% more, but gamers, for instance, are already willing to pay 50% markups (or more) for a 1% performance bump (if that). You could even market it as overclocker-friendly: the error checking will tell you when you're overclocking too high, and the error correcting will help you when you're right on the edge. It could also allow overclockers to identify DIMMs which can't keep up without the laborious process of "pull out a stick, run memtest overnight; put stick back in, pull out a different one, run memtest overnight; etc." (Or the worse one when DIMM has to be installed in pairs. Then you get the joy of testing every combination.)
No, it's not the exact same thing, because the batteries are different. It may be that some battery designs - even in the same general family (e.g. 9-cell Li-Ion) - are more tolerant of this sort of contamination than others. It may also be that Sony redesigned their batteries after the last recall to make them more tolerant of metal particle contamination, or changed their manufacturing process to make any such contamination less likely to be "critical." Hell, maybe Dell even started redesigning their laptops to work around Sony's problems. I don't know if any of those things are technically feasible or even possible, but I suspect you don't know either.
Certainly the similarity in the cases suggested that investigation was warranted (and they did investigate it). And it turns out, with our 20/20 hindsight, that a recall was warranted too. But this could be a pretty complex technical issue, and the recall is probably going to cost Dell (and eventually Sony) a couple hundred million bucks. It's easy for you to spend Dell's money, but if it were yours, I rather suspect you'd hesitate until you had all the facts. Even if you're firmly in the "Big Business is evil!" camp, remember that the money going to the recall could also have been spent improving wages or offering training for their call center employees in India, hiring more engineers in the US, or hell, paying Sony more per battery to increase their quality controls.
No, programs don't understand anything, which is the GP's point. You are glossing over the tremendous amount of work required to design a program which is capable of distinguishing between verbs and nouns and behaving appropriately. Human brains are incredibly complex, we have constant exposure to language, science indicates that our language is closely tied somehow to the way we think - language shapes brain development, vice versa, or both - and most of us still have trouble with it at times. It took me two passes to make syntactic sense of the GP's example sentence for all that I'd seen it before.
There is a subtle difference in meaning between split and unsplit infinitives. Let's use your example, modified:
There is no reason to not split an infinitive.
We actually end up with a new verb, "not split." What is there no reason to do? Not split an infinitive. This changes the meaning from "Don't do [X]" to "Do [not X]." The two statements are logically different constructs. "Don't drive red cars" vs "Drive cars that aren't red." The difference is subtle but important, and yes, it's one that most people do grasp. The problem is spoken English. By using emphasis, you can convey your meaning regardless of where the words fall: by emphasizing "not" you can make the split and unsplit variants equivalent. Because people are accustomed to making the distinction aloud, they don't always realize that they're not conveying the full (or correct) meaning.
So "don't split infinitives" does make sense, because the unsplit version is the one people almost always want. As you correctly note, it's not law, it's a rule of thumb. If you know what you're doing, you can boldly split infinitives where none have been split before.
That is because there are over 100,000 methods in the java api!
I've got 66,037 on my Python install, which does not include C and other non-Python native functions. 12,989 class definitions, by the way. (Just some find/xargs/grep/wc magic for ballpark figures.)
I am sure perl or python would be even slower if it had that many api's to dynamically compile into bytecode.
Er, not if you don't actually use them. It's not like you fire up a Python or Perl program and it loads every library on your system just to display "Hello, world!" to the screen. It's also worth mentioning that Python modules, at least, get byte-compiled when they're installed. They only get recompiled if you change the source, making the compiled version obsolete.
Java is semi native and not %100 interpretted
I don't have anything to add here, I just wanted to look at this while I was writing my reply.
What I want is an ethernet-based (iSCSI) consumer-grade SAN. I want to buy a box with five or six drive bays, pack it full of 500GB SATA disks, and then send it over the network to my desktop. That would be perfect for me. As an add-on, there could also be a head unit that plugs into the disk box (or many disk boxes on a consumer-grade gigabit switch) and does RAID, SMB, NFS, whatever.
I don't understand why there aren't any products like this. I can buy an adapter that goes into 3 5.25" drive bays and turns them into 5 3.5" hot-swap drive bays for about $80. To turn SATA (or IDE) into iSCSI, each box would need a CPU, but nothing too powerful. It would also need a gigabit ethernet port, but those are cheap nowadays. The head unit would be more expensive, but I think $200-$300 would be a reasonable price. (On-topic: FreeNAS could power the head unit.)
Store and forward is when the switch reads in the entire packet before making a routing decision. Most protocols, including Ethernet and TCP/IP, send the target address very early in the frame precisely so that store and forward isn't necessary. Instead they use a strategy called cut-through switching, where they read just enough of the frame to determine where to send it and then send the remainder to the destination port as it arrives on the source port. Most home or small office switches use store and forward switching.
Or maybe you were being pedantic and quibbling about calling it store and forward ethernet instead of store and forward switching.
You're not being cynical, you're being optimistic. Keep an eye out for the "X is also owned by VA" or "X is also part of OSTG" notes. Think about the effect a Slashdotting (against a capable server) has on the revenue of an ad-supported site.
Now unlike much of Slashdot, I don't see a conspiracy everywhere. I don't actually believe that's why VA/OSTG articles make Slashdot. I also don't believe that ZDnet received money from MS in exchange for a good review. As the saying goes, never explain by conspiracy what can be explained by incompetence.
Wasnt the goal of BSD to be secure and reliable, like debian, only moreso?
There is no "goal of BSD." There are at least four major open source BSD-derived OSes and they all have different goals. Of course every operating system tries to be secure and reliable - even Windows - but you're probably thinking of OpenBSD, where they are willing to sacrifice just about anything for the sake of security.
FreeBSD and DragonflyBSD, to name two, have always had user-friendliness as a major goal (among many others).
On whether the game will be succesful; it's essentially a new gametype (or mix thereof) by an industry vet, it's being hyped to hell and back, and it's got the backing of EA. I hear echoes of Black and White, and the echoes do not sound good.
That's exactly right. Any significant departure from what's been done a billion times runs the risk of being a dud. In fact, I'm sure that Spore will have a lot of annoying problems and frustrating bugs. Which I think is why EA sees franchise potential for it, perversely. The first Spore - sequels may not be called "Spore 2," they may just be similar in terms of gameplay and approach - will help future developers identify things that need to be improved and expanded on. Subsequent games can address Spore's inevitable shortcomings until they get it right.
For example, the multiplayer aspect of Spore seems very MMO-like. I can definitely imagine a galactic conquest metagame being built in or added on later. What EA's after with its franchises are a steady, recurring revenue stream, and MMOs sure give that. With the added bonus that all the new content is designed by players!
Mainly what Wright needs to do is make a game that's good enough that people will buy it, which will demonstrate to everybody that his basic idea is sound. From there he and others can just keep working until they get it right. I very much hope they're successful. Spore is the game I've wanted since I first started playing computer games. Which I guess is the source of the hype: it's the game everyone's always wanted.
I went over a couple times back when I was in high school and college and had no income. Then at some point the card just started getting declined. I assumed it was because technology had caught up, but maybe it's just because I'd bounced three or four debits. Or maybe my bank changed the policy, I don't know. Ever since I got a job I haven't run out of money (though when I got my car and had to pay all the up-front costs AND all my monthly bills came due a week later, I got uncomfortably close).
It's just too easy to get in trouble with a credit card, especially when you're young and the concept of managing real money is new and unfamiliar. I don't know many people in their 40s with big credit card debt, but I know lots of people in their 20s and 30s (the latter mostly still paying off debt they accumulated as the former) with big debt. Debit cards are much more effective at forcing you to live within your means since I don't think they'll let you overdraft at all any more. They certainly won't let you go over by more than $100 or so.
So I guess I'd revise your comment. Debit cards are for people who can't or shouldn't get credit cards.
That's a neat idea, but I'm afraid that a swarm of level 1 zombies desperately trying to become human again will quickly result in an exodus of players frustrated with the zombie experience. After all, if it takes 20 zombies to take down a human, 19 of those zombies are going to be unhappy even if they're successful. Which of the 20 wins? The one who strikes the last blow? That seems unfair. And if you have to go through 10 zombie raids to become human, only to die (as a human to another zombie raid) ten minutes later, that would quickly drive most players away from the game.
I like your idea of low-level zombies, but I think a cap of level 1 is way too low. I say pick a fraction like 1/5. When a human dies, he loses 4/5 his levels. Zombies get experience 1/5 as fast as humans. When a zombie becomes a human, he gets all his human levels back, plus his accumulated zombie xp - but that zombie xp is not multiplied by five, so the xp penalty sticks. Then make it somewhat challenging to zombify a human. Like you have to use some special attack when the human's below 10% health but still alive. That could make being a zombie fun enough that some people would rather be zombies than humans, at least sometimes. Hopefully that would keep zombified players from quitting en masse, keep the populations somewhat balanced, and make raids less arbitrary.
Regardless, I think it's a neat idea and I wish we saw more like it. Even if your zombie game were a dismal failure it'd sure be interesting!
It's essentially an append-only remote filesystem. That comes with both benefits and drawbacks. The fundamental benefit is point-in-time recovery. Coincidental benefits include dramatically lower average throughput (since backups are always happening) and the potential for lower total backup bandwidth (if a 5GB log file gets 200MB of new entries, an incremental would have to back up the entire 5.2GB log file; a log-based backup system would only back up the new 200MB). It would probably also make the backup admin's life easier by making backup traffic far more constant, so he can better plan how fast his hardware needs to be.
The downside is that this can end up taking much more space (if you delete and recreate a 50MB file ten times a day, the entire file is backed up ten times versus just once with a typical daily-incremental scheme). Restores can also be much slower depending on how often checkpointing is done. Doing checkpoints too often can defeat the advantages of logging, but done too infrequently the backup server will have to analyze an entire week's worth of data just to restore one file.
I do think "backup logging" is the way of the future. The advantages are too important for it not to be. It just may take a few more years before we're really ready for it, in large part because it requires significant cooperation from the operating system to be done well. Even filesystem snapshots are still somewhat immature and underutilized by OTS backup solutions, and we've had those for years and years.
If you're a programmer, I guarantee that you're using OOP even if you don't use an OOP language.
Consider the Unix read() function, which can read from any file descriptor: regular file, block or character special, socket, and so on. If you were to write such a function in C, you'd write some code to determine the underlying type of descriptor. Then, based on that type, you'd call a helper function - read_file(), read_special(), read_socket() - to perform the actual read.
Guess what? That's OOP. The file descriptor is the object. The code at the top of read() is determining the object type (or class). And the helper functions are class methods. If this is a big project, odds are you'll put all the helper functions for sockets in socket.c, for files in file.c, and so on. And there we have encapsulation (of the namespace variety) too.
As noted many times, you can write an OOP in any language. It's just easier to do it in a language that's designed for it. The compiler (or interpreter) does more of the work for you. For instance, you don't need to write the type-checking code, nor do you need to pollute your namespace and worry about collisions. And if you later want to add a new descriptor type, such as for a userland memory-based file, all you need to do is write a new class. All the functions or classes which operate on the other descriptor types will work, unmodified, on the new type. (That's the real code reuse: on the application side, not the library side.)
What possible discussion can there be when someone says "nothing to see here, move along"? They are indicating they aren't interested in rational discussion or debate.
I'm not quite willing to concede that - NTSHMA is basically Slashdot-speak for QED - but even if I were, Slashdot is a public forum. It's possible that someone else would see our well-formulated, intelligent replies and jump in to argue the original position better. Or maybe some lurker who was nodding his head reading the original post would have second thoughts and decide to do some research on his own. (Even if he doesn't change his mind, he's better-informed. And two rational, well-informed people can disagree. Maybe next time around he'll be changing our minds.)
Not to be an ass, but your original reply was as useless as you're saying the original post was. And yet here we are having what is, in my opinion, a pretty rational, intelligent discussion, one which others might find valuable. Of course, we're not talking about wiretaps at all. But considering the self-congratulatory circle-jerk of most of the other comments on this story, maybe that's for the best.
Of course there is. You give a few examples showing why he's wrong. Then he, if so inclined, can reply with counterexamples or explain why your examples don't mean what you think. This process is called a rational debate, and I'm not surprised you aren't familiar with it. This is Slashdot, after all. But even here, you can still have one if you try. I manage to, from time to time, and I usually find them very interesting and enjoyable... even when everyone disagrees with me. I hope those debating against me feel likewise. Sometimes I even change my mind!
See? That's what a polite response to ignorance looks like.
I think you're confused. Any freedom we have which is not guaranteed by the Constitution can be abridged or eliminated entirely by Congress. That's the way our government is set up. The court's just saying Congress has the legal authority under the Constitution to pass this law (or create a regulatory agency which has legally binding rules).
If the result is unpalatable to you, then you probably ought to get an Amendment passed. Because the court's ruling seems pretty self-evidently correct here, which I think we can all agree is a rarity for the 9th.
IA32 is Intel's name for x86. It never really caught on because I don't think they started using it until the Pentium, when "x86" obviously stopped making sense. It may well be that HP is confusing things by misusing the term, but I assure you, IA32 is x86. Look at Intel's 32-bit ISA documentation on their site if you don't believe me. Since the P3 at least they've exclusively used IA32 to describe the "x86" ISA.
Most elevators now have sensors in the doors so they don't close on somebody. The ones at work also have weight sensors. The two systems put together are reasonably accurate at letting the elevator guess how many people are inside. So if a floor button is hit once, as soon as the elevator detects one person leaving it will close the doors immediately. If the button's hit twice, the elevator will hold for a few seconds to give the second person a chance to get out. Similarly, after someone gets in the elevator it will hold to give them a chance to select a floor. We've all quickly learned to hit "L" at the end of the work day rather than wait 10 seconds for the elevator to give up and keep going.
I'm told that this system will also prevent someone hitting all the floor buttons since the elevator knows roughly how many people are in it and won't let you choose many more floors than people. (But not being a jerk, and also not being willing to wait five minutes to get to my floor, I haven't tested.)
The Secret Service is part of Treasury. They also deal with things like counterfeiting rings. As Treasury is going to be involved in large-scale financial fraud investigation, and Secret Service is an enforcement arm of Treasury, this makes sense to me.
It all seems like stuff the FBI ought to be doing, but I think that's mainly an artifact of how crime has changed. Federal law enforcement was originally designed to go after the mob, and you get the mob by following the money. So it makes sense for Treasury to handle that, and so they got the Secret Service. (Think Elliot Ness in The Untouchables.) But as the mob dwindled in significance, or perhaps as other interstate crimes became more significant, the FBI, which was a more general-purpose agency, became dominant. Now just about anything can fall under the FBI's purview. So I'm sure Treasury will jealously guard any area where it can claim authority or Secret Service will become what everyone already thinks it is: nondescript guys with earbuds and suits who hang out with the President all day. Well, nondescript guys who can somehow conceal assault rifles under their suit coats.
Or maybe, what with the name and all, they're happy about the relative anonymity.
Slashdot Mirror
Remember that for broadcast TV (in the US at least), you're not the customer, you're the product. Advertisers are the customers. Google can make money off TV advertising the same way they do everywhere else: by making ads more successful and therefore more profitable for advertisers. That lets networks charge more for advertising space and time, and Google takes a cut of that. The profit isn't in owning the pipes, it's in owning the eyeballs.
There's also the synergy angle, i.e. Google can tightly couple TV advertising with Web advertising. "Joe just saw an ad on TV for X and started Googling for information on it five minutes later, so let's show him ads for stores in the area which sell X." Going back to what I said before, with regards to Web advertising, Google pretty much owns all the eyeballs, so this has the potential to be really profitable for them.
Wow. I am not, nor have I ever been, an employee of the meat industry, or any other food-related industry. My sole association with them is eating some of their products. Seriously, tinfoil hat much? The mere fact that someone disagrees with you doesn't mean your opponent's taking bribes.
So am I, but truth doesn't imply completeness. The line needs to be drawn somewhere. That cow you want to eat may have ingested some kind of poison which suffused every cell of its body, and by eating it you could die. So it seems relevant, except that every slice of roast beef would have to include a 5000-page manual. At a certain point, we have to trust that the experts (that would be the FDA and other organizations) are, in fact, experts.
So considering that the overwhelming preponderance of scientific opinion on the matter is that these things are, in fact, perfectly safe (and safer than eating bacteria), it's perfectly rational and correct for the "default" case to be "virus included."
But not to worry. I'm sure someone is already out there forming a company to sell "Organic Lunchmeats" with all the original bacteria intact. With truth in labeling the virus-adding players won't be able to make the same claim, so you'll be able to tell the sides apart that way. Just like when you're buying pesticide-free food, non-GM food (in the US), rBGH-free dairy products, etc. Since you're probably the sort of person who buys all those things anyway, it will probably be more convenient for you too: just buy everything that says "Organic" or "All-Natural" on the label!
Agreed, but bear in mind that a single-bit error doesn't have to crash your system (or an app). In fact, it usually won't, because the amount of "critical" memory is very small relative to the total amount of RAM installed. Instead it will silently corrupt data. This could result in a momentary glitch in what's shown on the screen; it could result in an app delivering nonsensical results; or, far worse, it could result in bad data being written to disk or an app delivering subtly wrong results. Since all modern operating systems use all memory in your box for something (cache, usually) pretty much every single-bit error is going to screw something up.
I work with many ECC-using servers and there are typically one to five single-bit errors per month. Even though I understand the reasons for it, I am kind of bewildered that ECC isn't more common on high-end desktop systems. The RAM costs ~15% more, but gamers, for instance, are already willing to pay 50% markups (or more) for a 1% performance bump (if that). You could even market it as overclocker-friendly: the error checking will tell you when you're overclocking too high, and the error correcting will help you when you're right on the edge. It could also allow overclockers to identify DIMMs which can't keep up without the laborious process of "pull out a stick, run memtest overnight; put stick back in, pull out a different one, run memtest overnight; etc." (Or the worse one when DIMM has to be installed in pairs. Then you get the joy of testing every combination.)
No, it's not the exact same thing, because the batteries are different. It may be that some battery designs - even in the same general family (e.g. 9-cell Li-Ion) - are more tolerant of this sort of contamination than others. It may also be that Sony redesigned their batteries after the last recall to make them more tolerant of metal particle contamination, or changed their manufacturing process to make any such contamination less likely to be "critical." Hell, maybe Dell even started redesigning their laptops to work around Sony's problems. I don't know if any of those things are technically feasible or even possible, but I suspect you don't know either.
Certainly the similarity in the cases suggested that investigation was warranted (and they did investigate it). And it turns out, with our 20/20 hindsight, that a recall was warranted too. But this could be a pretty complex technical issue, and the recall is probably going to cost Dell (and eventually Sony) a couple hundred million bucks. It's easy for you to spend Dell's money, but if it were yours, I rather suspect you'd hesitate until you had all the facts. Even if you're firmly in the "Big Business is evil!" camp, remember that the money going to the recall could also have been spent improving wages or offering training for their call center employees in India, hiring more engineers in the US, or hell, paying Sony more per battery to increase their quality controls.
No, programs don't understand anything, which is the GP's point. You are glossing over the tremendous amount of work required to design a program which is capable of distinguishing between verbs and nouns and behaving appropriately. Human brains are incredibly complex, we have constant exposure to language, science indicates that our language is closely tied somehow to the way we think - language shapes brain development, vice versa, or both - and most of us still have trouble with it at times. It took me two passes to make syntactic sense of the GP's example sentence for all that I'd seen it before.
There is a subtle difference in meaning between split and unsplit infinitives. Let's use your example, modified:
We actually end up with a new verb, "not split." What is there no reason to do? Not split an infinitive. This changes the meaning from "Don't do [X]" to "Do [not X]." The two statements are logically different constructs. "Don't drive red cars" vs "Drive cars that aren't red." The difference is subtle but important, and yes, it's one that most people do grasp. The problem is spoken English. By using emphasis, you can convey your meaning regardless of where the words fall: by emphasizing "not" you can make the split and unsplit variants equivalent. Because people are accustomed to making the distinction aloud, they don't always realize that they're not conveying the full (or correct) meaning.
So "don't split infinitives" does make sense, because the unsplit version is the one people almost always want. As you correctly note, it's not law, it's a rule of thumb. If you know what you're doing, you can boldly split infinitives where none have been split before.
I've got 66,037 on my Python install, which does not include C and other non-Python native functions. 12,989 class definitions, by the way. (Just some find/xargs/grep/wc magic for ballpark figures.)
Er, not if you don't actually use them. It's not like you fire up a Python or Perl program and it loads every library on your system just to display "Hello, world!" to the screen. It's also worth mentioning that Python modules, at least, get byte-compiled when they're installed. They only get recompiled if you change the source, making the compiled version obsolete.
I don't have anything to add here, I just wanted to look at this while I was writing my reply.
I don't understand why there aren't any products like this. I can buy an adapter that goes into 3 5.25" drive bays and turns them into 5 3.5" hot-swap drive bays for about $80. To turn SATA (or IDE) into iSCSI, each box would need a CPU, but nothing too powerful. It would also need a gigabit ethernet port, but those are cheap nowadays. The head unit would be more expensive, but I think $200-$300 would be a reasonable price. (On-topic: FreeNAS could power the head unit.)
There must be someone making this.
Or maybe you were being pedantic and quibbling about calling it store and forward ethernet instead of store and forward switching.
Now unlike much of Slashdot, I don't see a conspiracy everywhere. I don't actually believe that's why VA/OSTG articles make Slashdot. I also don't believe that ZDnet received money from MS in exchange for a good review. As the saying goes, never explain by conspiracy what can be explained by incompetence.
FreeBSD and DragonflyBSD, to name two, have always had user-friendliness as a major goal (among many others).
Man, I gotta take a wicked Revolution.
For example, the multiplayer aspect of Spore seems very MMO-like. I can definitely imagine a galactic conquest metagame being built in or added on later. What EA's after with its franchises are a steady, recurring revenue stream, and MMOs sure give that. With the added bonus that all the new content is designed by players!
Mainly what Wright needs to do is make a game that's good enough that people will buy it, which will demonstrate to everybody that his basic idea is sound. From there he and others can just keep working until they get it right. I very much hope they're successful. Spore is the game I've wanted since I first started playing computer games. Which I guess is the source of the hype: it's the game everyone's always wanted.
I went over a couple times back when I was in high school and college and had no income. Then at some point the card just started getting declined. I assumed it was because technology had caught up, but maybe it's just because I'd bounced three or four debits. Or maybe my bank changed the policy, I don't know. Ever since I got a job I haven't run out of money (though when I got my car and had to pay all the up-front costs AND all my monthly bills came due a week later, I got uncomfortably close).
So I guess I'd revise your comment. Debit cards are for people who can't or shouldn't get credit cards.
I like your idea of low-level zombies, but I think a cap of level 1 is way too low. I say pick a fraction like 1/5. When a human dies, he loses 4/5 his levels. Zombies get experience 1/5 as fast as humans. When a zombie becomes a human, he gets all his human levels back, plus his accumulated zombie xp - but that zombie xp is not multiplied by five, so the xp penalty sticks. Then make it somewhat challenging to zombify a human. Like you have to use some special attack when the human's below 10% health but still alive. That could make being a zombie fun enough that some people would rather be zombies than humans, at least sometimes. Hopefully that would keep zombified players from quitting en masse, keep the populations somewhat balanced, and make raids less arbitrary.
Regardless, I think it's a neat idea and I wish we saw more like it. Even if your zombie game were a dismal failure it'd sure be interesting!
The downside is that this can end up taking much more space (if you delete and recreate a 50MB file ten times a day, the entire file is backed up ten times versus just once with a typical daily-incremental scheme). Restores can also be much slower depending on how often checkpointing is done. Doing checkpoints too often can defeat the advantages of logging, but done too infrequently the backup server will have to analyze an entire week's worth of data just to restore one file.
I do think "backup logging" is the way of the future. The advantages are too important for it not to be. It just may take a few more years before we're really ready for it, in large part because it requires significant cooperation from the operating system to be done well. Even filesystem snapshots are still somewhat immature and underutilized by OTS backup solutions, and we've had those for years and years.
Consider the Unix read() function, which can read from any file descriptor: regular file, block or character special, socket, and so on. If you were to write such a function in C, you'd write some code to determine the underlying type of descriptor. Then, based on that type, you'd call a helper function - read_file(), read_special(), read_socket() - to perform the actual read.
Guess what? That's OOP. The file descriptor is the object. The code at the top of read() is determining the object type (or class). And the helper functions are class methods. If this is a big project, odds are you'll put all the helper functions for sockets in socket.c, for files in file.c, and so on. And there we have encapsulation (of the namespace variety) too.
As noted many times, you can write an OOP in any language. It's just easier to do it in a language that's designed for it. The compiler (or interpreter) does more of the work for you. For instance, you don't need to write the type-checking code, nor do you need to pollute your namespace and worry about collisions. And if you later want to add a new descriptor type, such as for a userland memory-based file, all you need to do is write a new class. All the functions or classes which operate on the other descriptor types will work, unmodified, on the new type. (That's the real code reuse: on the application side, not the library side.)
Not to be an ass, but your original reply was as useless as you're saying the original post was. And yet here we are having what is, in my opinion, a pretty rational, intelligent discussion, one which others might find valuable. Of course, we're not talking about wiretaps at all. But considering the self-congratulatory circle-jerk of most of the other comments on this story, maybe that's for the best.
See? That's what a polite response to ignorance looks like.
If the result is unpalatable to you, then you probably ought to get an Amendment passed. Because the court's ruling seems pretty self-evidently correct here, which I think we can all agree is a rarity for the 9th.
The "I" is for Intel, not Itanium.
I'm told that this system will also prevent someone hitting all the floor buttons since the elevator knows roughly how many people are in it and won't let you choose many more floors than people. (But not being a jerk, and also not being willing to wait five minutes to get to my floor, I haven't tested.)
It all seems like stuff the FBI ought to be doing, but I think that's mainly an artifact of how crime has changed. Federal law enforcement was originally designed to go after the mob, and you get the mob by following the money. So it makes sense for Treasury to handle that, and so they got the Secret Service. (Think Elliot Ness in The Untouchables.) But as the mob dwindled in significance, or perhaps as other interstate crimes became more significant, the FBI, which was a more general-purpose agency, became dominant. Now just about anything can fall under the FBI's purview. So I'm sure Treasury will jealously guard any area where it can claim authority or Secret Service will become what everyone already thinks it is: nondescript guys with earbuds and suits who hang out with the President all day. Well, nondescript guys who can somehow conceal assault rifles under their suit coats.
Or maybe, what with the name and all, they're happy about the relative anonymity.