You're still using the original CPU that came with your computer? There's probably not much left of it by now. Lots of programs have CPU leaks. Sure, you can deal with it by restarting stuff over and over again, but you'll just have to keep doing it. It's a lot more convenient to just buy a bunch of extra CPUs and swap them in when the older ones get used up.
I've been buying them by the 6-pack at Fry's. It's much easier now that popular OSes support hot-swappable CPUs, though I'm never sure how long I'm supposed to put them in the toaster first.
(Btw, please file a bug. Or switch to a FF4 beta first to see if it still happens there. That may also may make it much easier to figure out whether it's a plugin, since they can run in another process in FF4.)
I love bashing the rich, Microsoft, and especially Ballmer as much as anyone but it's kind of hard to overlook the glaring logic error in the cynicism: whether or not that measure passed would have no effect on Ballmer's stock sales before the end of the year anyway. I suppose it would've looked a little worse if the measure passed and he immediately dumped a bunch of stock, but somehow I don't think that PR problem is worth the effort and expense.
Err... so you are taking a patient providing a guaranteed revenue stream from staving off a terminal illness, and replacing him/her with a patient with a possibility of providing a smaller revenue stream, maybe for a longer period if you're lucky?
And this is a patient who almost died and suffered through uncountable procedures and doctors and uncertainty, and you think they'll jump at the chance to play with even more pills and doctors? Everyone I know who has had a serious encounter with the medical establishment would do almost anything to avoid having anything to do with doctors again. And that includes dying. (Yes, it's anecdotal, but I have deceased family members in precisely this category.) Younger people especially may find the idea ludicrous, but the idea of living at all cost becomes far less appealing once you become personally acquainted with that cost.
But what about the other much-maligned member of the "health care" industry: insurance companies? They would save a ton of money if somebody came up with a proper cure. Not only would they not have to pay for the expensive last-ditch drugs for the currently incurable disease, but they wouldn't need to treat all of the complications that arise from late-stage terminal illness.
People would probably freak out if the "evil insurance industry" started to dabble in researching their own drugs and treatments, but they are the ones with the incentive. This whole idea was given to me by a friend of mine, who once suggested to a high-level insurance representative that they should be awarding bounties for cures. It makes a lot of sense, even though bounties are obviously limited in what activities they can support.
(Note: the quotation marks around "evil insurance industry" should not be taken to mean that I actually disagree with the label; personally, I find the insurance industry as it is currently set up to indeed be a systemic evil. I'd much rather they sold insurance for catastrophic health expenses, rather than being an integral part of the payment and approval process.)
Or pay kids twice as much and get double the benefit!
Better yet, don't bother with the other 95% and just pay the $500! You'd save billions!
You may argue that that isn't at all what you said, but your statement is equally ludicrous. You're trusting badly insufficient base data and going off and calculating meaningless resulting figures. Are you in marketing, by any chance?
Have you factored in whether the improvement is sustained, which wasn't tested in the study?
I would bet that removing the rewards would actually make these students do worse than they did before the study started. Have you factored in that possibility?
Has any learning actually increased, or just the test scores? They're nowhere close to being the same -- cheating, cramming, and test-taking strategies are just some of the obvious ways to inflate test scores while keeping learning (of the tested material) constant or declining.
Is there collateral damage? As in, do these students stop studying for any subject that they don't get paid for, or other things in their lives? Might need to factor that in.
As a former employee of Reactrix Systems (may it rest in peace), I know something of this space. We had this working a few years ago (ok, we were on Linux and using the Tyzx 3D camera.)
I'm happy to see that MS bought 3DV. 3DV has been promising that their camera will be available at scale for years. I talked to them at GDC a year and a half ago. "It'll be out this summer." "Who's your manufacturer?" "Oh, we don't have one yet. We'll just get someone in Taiwan or China to do it. Manufacturers are a dime a dozen."
So are companies with unbuildable products. I had to resist the urge to laugh in his face -- they didn't have their sh*t together in February and they'd have product on the shelves in the summer? I pretty much gave up hope on them then.
Which is too bad. They have a nice product -- not as good as Tyzx or PrimeSense, but theoretically it could be far less expensive.
Don't think of the EyeToy. That's a simple 2D differencing system, and not a very good one. I actually think it's a good product overall -- not enough so that I'd bother to buy one, but you could have fun with the right content. The vision system could be done better even with the harsh constraints (working in just about anyone's living room is surprisingly difficult.) But 2D images are fundamentally limited.
A depth-sensing camera like the Z-Cam, Tyzx, or PrimeSense can pick out gestures in front of your body, it can measure direction and acceleration in 3D, and it can pick players out from the background far better.
At the same time, our intuition was (and our experience found) that trying to convert camera input into controller input is just a bad idea. You don't want this for playing Halo 3. You need games built for camera input. It's fun for more than games, too -- we prototyped some nifty photo, video, and 3D model interfaces.
One of our most eyecatching prototypes was a light saber game where you could slice through oncoming hordes of robots. The video is dark and not very well done, sorry.
It is not impossible to use a public terminal securely -- it's just another example of tunneling secure data over an insecure link. One thing that some reponses neglect is that for many applications, the data coming back is just as critical to keep secure as the data (passwords etc.) going in. Unless you want everyone reading your email and seeing your bank account balances and pictures of your cute naked children.
Of course, to tunnel over an insecure link, you need secure endpoints. The remote endpoint is easy; it can be your server or proxy or whatever. It sounds like the Blackdog is an example of something that can provide the local endpoint. All that is needed is something that encrypts outgoing data and decrypts incoming.
I suggest Pig Latin. You use your laptop/PDA/whatever normally, except you convert your password to pig latin and your home proxy server transforms all incoming text in the same way. Sure, that only works for text, but I have a brilliant idea for an image transformation that works on the same principle: you take every image, move the first column of pixels to the end, and add 13 to each of the RGB values in that column (modulo 256). I think it should be pretty much invulnerable to decryption by unwanted snoopers, because it combines the full security of pig latin with that of ROT13.
I plan to file for a patent and start up a company based on this technique. Anyone who would like to get in on this incredible opportunity now is encouraged to send me their seed investments in small unmarked bills. No need to put on your return address; I have another algorithm that I plan to use to infer the sender's contact info based purely on the rest of the packaging. So far it only accurately estimates the sender's intelligence level, but I'm sure that by the time you send me the cash, I'll have it working well enough that I'll be able to tell everything I need to know about you.
Most mammals can do it naturally when they're young, but the ability disappears almost completely with age. However, even older rats have been induced to regenerate limbs. There seems to be a critical level of nerve density required to trigger regeneration (actually, it looks like it might not be the nerves themselves, but rather the Schwann bodies surrounding the nerves). In mammals, the density is too low. Adding a very small DC current will cause certain cells to dedifferentiate into at least pluripotent stem cells, then redifferentiate to regenerate the lost tissues and structures. Well, that and creating an artificial neuroepidermal junction, which can be done surgically be rerouting the nerve. (In frogs, a non-mammal that cannot naturally regenerate except when young, the cells that revert to stem cells are red blood cells, oddly enough. Their red blood cells still have degenerate nuclei that can be reactivated. That seems to be a major reason why regeneration is so rare in mammals; our red blood cells don't have nuclei at all, and hence cannot be used. Fortunately, it appears that there are other cells floating about that will respond.)
Of course, until recently all of this flew completely in the face of conventional medical beliefs, so I should warn that I'm giving you the opinions of a crackpot. (A crackpot who published much of this work in journals like Nature, and whose work has been reproduced at least in part. But considering that researchers still don't seem to have caught up with his work from the 70s, I'm guessing he's still considered a crackpot.)
You, too, can read about this crazy crackpot's research in "The Body Electric", by Robert Becker and Gary Selden. And if you're interested in what I wrote above, you probably should, because I wrote from my memory of reading the book. So it's almost certain to be a horribly distorted version.
If you take a somewhat longer view, then you'll immediately see that the referenced study is obviously correct:
Let's see, we have a new occupation, with nothing to build on, but lots of stuff that can be done (profitably). Then a ton of people will flood into it, and there will massive duplication of effort as everyone builds up the same little building blocks (some of them selling them to each other). If there are other people somewhere that could accomplish the same thing, then they will eventually start doing it too, and undercutting the original people. It will take longer if there is a higher barrier to entry (required education or equipment or whatever), but eventually economic pressure will win. Dams will always fail eventually.
At the same time, the shared infrastructure and knowledge base will gradually grow, and there will be less need for the bottom people who are all doing the same thing over and over again, and more need for the higher level people who can take larger pieces and use them to reach further. At the same time, no level in the hierarchy is ever likely to die out completely.
That describes where the software field is today, but it could be a description of nearly any occupation: building cars, digging holes, feeding people, making games,... (well, certain ones -- eg prostitution -- have different characteristics.)
I don't know whether the study is accurate as of today, but it'll be more true as time goes on.
No, not really. Read the whole thread. Roman's work really doesn't change the structure of the CFS much at all, and the structural change he does make can be applied independently of the other changes. It's true that Roman and Ingo disagree about how "big" of a change it is: Roman thinks it's major, but if you keep reading, you'll see that he's only referring to the mathematical changes; Ingo feels it's a minor refinement of the math that could be done to the existing CFS without disrupting much else.
So Roman is trying to propose an architectural change and Ingo is sidelining him? Well, he does propose one structural change and one mathematical one, which sums up to an architectural change, I suppose -- but either can be done independently of the other, on the current code base. The remaining changes are renaming a file, removing lots of comments, and removing some of the capabilities of the existing CFS (which are orthogonal to what Roman is working on.)
It certainly does not sound like Ingo secretly thinks that Roman's work just sucks, but he is unconvinced that Roman is attacking a particularly relevant problem. Roman is fixated on rounding errors, which Ingo feels are rarely relevant. Either of them could be correct for all I know.
Beyond that honest disagreement, which will have to be resolved with test cases, I have to say it's hard not to side with Ingo. Roman's work could clearly have been presented in a way that would have been much easier to both understand and integrate, but instead he chose to (among other things) copy one whole file and rename it rather than patching it. I've merged in enough messy third-party patches to recognize a situation where someone just can't be bothered to do all of the work needed when you are developing on a shared code base. Imagine that someone finds an off by one bug in your code: it should have been while (a = b), but you wrote while (a b). They send you a patch with that change along with reformatting all of your comments and re-indenting 80% of the code. Not helpful. Even if their version is prettier. (And if it is, then splitting it into two patches would get all of the advantages, at the cost of more work for the patch submitter.)
The "good" students (in the sense that you seem to mean it) will go to the lecture in the first place, and won't need the podcast (if you sat through the lecture once, do you really want to go through it again at the same slow speed?)
The bad students are going to skip all the lectures, zip through all of the podcasts just before an exam, and fail anyway. Without the podcasts, they'll show up for some of the lectures, cheat off of their friends during the assignments, get copies of the podcasts from the same friends, and fail anyway. So it doesn't matter for them either.
The lazy students -- which is 90% of them, but we won't count the ones that fall in either of the preceding categories -- will use the existence of the podcasts as an excuse to not show up to class, will try to sail through them just before exams, and will discover that they can't absorb that much that fast. Those are the ones you're worried about.
I disagree with the other posters who say that there is no issue. I am one of those lazy students. I ended up doing pretty well as an undergrad and then getting an MS from UC Berkeley. In other words, I am one of the people who did well in the absence of those podcasts, and therefore am exactly the sort of person you wouldn't want to do worse if they were available. And my attendance record wasn't exactly stellar to begin with. With the added temptation of postponing a class via a podcast, I suspect I would have royally botched things up. It would have been 100% my own fault, of course, but the whole point of a university is to establish an environment conducive to learning (if you'll forgive the excess syllables.)
For the most part, that means presenting readily available information in a form that students are likely to pick up on, and doing so within a structure that encourages them to do so -- rather than cater exclusively to their much stronger short-term urges to get laid, hang with friends, and catch some Zs. So if some part of the structure makes it less likely for students to learn, even if it's totally those students' fault, then it's not a good idea for the university to set it up that way.
Still, your authentication schemes sound like way overkill. I can think of a couple of possibilities:
1. Have regular homework assignments that use the information in the lectures. Any class for which this makes sense should be doing this anyway, and anyone who is blowing off the homework needn't be catered to.
Still, I can think of a lot of classes I've taken that were more project-focused, and it seems silly to change them around merely because of the existence of podcasts. So...
2. During each lecture, verbally give the code to access the next lecture. Alone, this just provides a little more incentive to keep up with things so you're not wading through a dozen lectures to get the one you really want, but you could also combine it with either of the next two.
3. Make the podcasts available for a limited time. Allow exceptions on a case-by-case basis. I don't think I'd really recommend this one. You might even create a black market for the things.
4. Require students to ask for them individually. Give them out freely whenever they do, even at the last minute. You can automate it, as long as the student knows that the professor can see exactly who they are and when they requested it. Require a written reason (ignored by the automation) for a little added push.
Personally, I'd go for #1 when applicable, #2 alone when not.
Or flip the problem on its head -- what if everyone were required (ok, requested) to listen to the podcasts before the lecture, and the lecture was a lot more interactive? You could pack in more material, the students are incented to view the podcasts so they're not completely lost during the "lecture", and you get a better mix of theory and (guided) practice. I'm not thinking of a Q&A/recitation/discussion session (or whatever your school calls them); I'm more thinking of specific, practical examples of the material covered.
The world is running more and more on information. Google is a primary conduit between people and the sea of available information. Google's strategy will be to own as much of people's information as possible, and to get between people and whatever other information is out there. It's not just about advertising; ads just happen to be one of the most direct ways of converting the information stream to cash. If you are a necessary part of the way people find things out, meet and manage their relationships with other people, read their email, shop for stuff, read their news, etc, etc, etc, then you become *the* person to talk to for anyone trying to sell a service that's related to any of those. Or anyone researching, gathering demographics, persuading voters, or -- as the future unfolds -- doing pretty much anything.
Google's only real vulnerability is in the court of public opinion, so privacy issues are a big deal. For now, they can't go too far for fear of public backlash. Soon, they will be held in check only by their "don't be evil" mantra. But the more money and power that their storehouse of information can provide, the harder it will be to resist using that information in unscrupulous ways. In my experience, you just can't trust in someone else's personal integrity to safeguard your interests; either that integrity will crack under pressure, or the person will be swept aside and rendered irrelevant. (Especially if it's a public company...)
I'll end with a little scenario. Someone bombs a building. Google decides to help out, and tells the FBI who bought the needed materials and when, everyone those people know, what they've looked for on the web, and what time they've been awake for the last few years.
Okay, the last is a stretch -- but I bet if I plotted every Google search I made against time, you could at least get a feel for what hours I'm keeping.
And they'll report the same for all of the bomber's acquaintances and those acquaintances' acquaintances, one of whom happens to be you. But don't worry; I'm sure the FBI would delete all that information once they were done with that case.
And I find your comment to be a brilliant description of why so many people erroneously believe that slapping a GUI on something magically makes it easy to use. There is a common mythology about both CLIs and GUIs that ends up doing a disservice to both. The problem is that each of your points is accurate, but in many cases they miss the point.
The perception of the CLI partly suffers from its strengths -- speed and power for advanced users. This makes everyone assume that it is only useful for those users for whom speed and power are important, namely advanced users, and not for newbies. A consequence of that viewpoint is that development of CLI features has long ignored the newbie issues -- the original article's use of a 'man commands' is a great example of a simple necessity that is sorely lacking. People put a lot of effort into pruning down GUIs for newbies or specific tasks, but something like 'man commands' will always get rejected for a CLI because it is not comprehensive, or because it "dumbs down" the interface. Is a pocketknife without a chainsaw and ice cream making attachment any "dumber" than one with? No, it's just more tuned to a set of tasks.
In fact, the CLI has a completely different set of advantages for newbies. I have a fair amount of experience in teaching newbies to use computers for the first time, and there just is no contest -- they have *always* preferred the CLI for those tasks that it is appropriate. A large reason for that is Post-Its: if they can jot something down on a Post-It, they will be able to remember and comfortably incorporate it into their daily tasks. GUI tasks are just not very Post-It compatible. (Note that I am only talking about newbies here; personally, I think that the easiest path for people is to start with the CLI, migrate to the GUI, then go back to the CLI.)
The primary advantage of GUIs that I see is the display of the available options, and most CLIs are sorely lacking here. Except that it ends up not helping newbies much, because all those "intuitive" associations between icons/menus and commands are lost on the newbie. Geeks really have no idea how foreign many of the basic computer concepts are to inexperienced people. Icons, for example, are horrible -- even if the user can recognize what an icon is supposed to represent, that doesn't mean they will understand the difference between a mail program and a particular mail message. "Why should I click on the little picture of the envelope? I've already done that and read the message that came up; I want to read the new ones! Where are they?" The whole desktop metaphor is a large stretch for people -- a real desktop starts out empty, with perhaps some little bits of furniture intended for various purposes. The user chooses where to put things and how to arrange stuff. Compare that to a computer desktop which is more akin to the control panel of a nuclear reactor, all laid out and ready for... who? Well, clearly for whoever set it up that way, not the naive user! The mixture of documents and applications and tools (wastebasket etc.) means that even if the user began with a mental model of a desktop, it will be quickly violated when they put something in the trash can and a big window pops up and yells at them.
Today's GUIs are not created with the mindset of a space in which a user can perform whatever tasks he/she cares about. Instead, they try to instruct the user in the "proper" way of doing things. Wizards and dialog boxes are great, but they are also saying that you have to do things in a particular order and enter a bunch of information that you don't really care about (at least not yet). "Are you sure you meant to do that?" -- why, is there something wrong with doing that?
Anyway, to respond to specific points:
CLI=dialog? Yes, it is imperfect. But understandable -- if you ask somebody to do something, they may or may not tell you that they've done it, or show you what it looks like having done it.
I don't need to scratch my head and search my soul to figure out whether God created the universe. I was there. I saw the whole thing.
God didn't create the universe. Well, He did, but not intentionally. God just wanted a beer. But you can't just create a beer floating in the middle of the void -- there's nothing satisfying about it. It would be like a book written by an illiterate person -- sure, he could put lots of black squiggles onto a bundle of pages that would vaguely look like a book, but it wouldn't mean anything.
So for a proper beer, God pretty much had to make up physics. I'm not just talking about the refinements needed to get it to foam just right -- I'm talking about the whole deal. After you drink some, there should be less left over, not more. Drinking a beer should not make you turn into beer yourself. Beers should not be smarter than the drinker. Well, not the first few, at least. The state of drinking beer needs to contrast with something, so the state of not drinking beer must also exist. In fact, that's where most of the world came from, because having the world exist in only two states (currently drinking beer/currently not drinking beer) just seemed too lame to a clever guy like God. Same idea for water and other liquids -- if He can drink beer, He really ought to be able to drink not-beer, just so He can say He chose the beer instead.
And then there's the whole question of origins. A beer is so much less interesting if it creates itself or just spontaneously comes into existence. A truly full-bodied beer needs a background, a character, a story. God went a little crazy with that, inventing those 'human' things with enough cleverness to invent stuff, curiousity to try things out, and a desperate need to get sloshed, smashed, trashed, and basically totally drucking funk. And all that cleverness and curiousity necessitated science. And dinosaur fossils. And religion. (God got a real kick when he realized he'd have to invent religion, I remember. Of course, he wasn't exactly sober by that time...)
Oh, and you know that bit about "...and on the 7th day He rested?" Purely an excuse to keep us from bothering Him during His hangover. We're still on the 7th day, see. I'm not even sure if He thought far enough ahead to make an 8th day. He was having some trouble with the notion of Time, and I recall Him saying something like "aw, screw it. Nobody's going to be drinking any beer at the speed of light anyway. I'll see you later -- I'm gonna go get wasted."
I'm really baffled at the constant attempts to shove CGI down our throats.
Try a little calculation: add together the salary paid to the animal trainer, the bribe money to pay off the SPCA, and of course the salary for the actor in the alien suit himself. Oh yeah, and his stuntman and the mechanical animal double. Subtract out the cost of 1000 hours on a render farm and half a dozen CG serfs. And don't forget the ego of a director who is tired of the actors getting all the credit.
You really can't help but cringe in those scenes in AOTC when Anakin is riding some beast (both in the field and in the gladiator arena). I mean, it's so obviously a CGI effect. It just doesn't move right.
I agree completely. I don't think there's been a movie mixing live action and CGI that hasn't made me squirm in my seat. It completely throws me out of the mood -- all that disbelief that was hovering suspended overhead suddenly comes crashing down. It's strange -- I can see the wires pulling CG characters around much more clearly than the wires attached to people who are flying around in all kinds of unbelievable directions.
But I disagree that CGI doesn't have a place in recreating creatures. There are a very small handful of scenes I've seen over the years where it really worked. They're pretty much all cases where the difference registered itself at some deep level as being very alien (instead of very fake.) It's a trip to watch something that moves almost like something I'm familiar with -- but not quite. Sends shivers up my spine.
But when it doesn't work, it really doesn't work. I don't understand why so many things make it to the screen when they just don't move right. The only explanation I can come up with is that you have to spend the time and money before you get to see whether it works, and by that time -- well, you've already spend the time and money.
It may not be a maintenance nightmare -- but it'll become one. Unless it is extremely simple or will only be worked on by one person, and in either of those cases, maintenance isn't a big concern anyway.
There are two problems: first, comments and code gradually diverge, no matter how well-disciplined the programmers are. Think of it this way: when you write code, you introduce bugs. Everyone does, no matter how good of a programmer they are. But those bugs have many ways of getting exposed and being fixed. Either the compiler will catch them, or the first run through the code will, or QA will. Now what's so different about comments? They are bound to contain bugs too. But the mechanisms for catching them (code reviews and the occasional poor sap who wanders through chasing after a bug) are much, much weaker. Result: buggy comments.
Second, the assumed significance of a comment drops proportionally to the density of comments. If there are too many comments, a reader will naturally tune them out. When you read a book and the writer introduces a new character, she'll never tell you that the new guy is a human being with two arms and two legs and more crotch hair than knee hair. She'll tell you what's noteworthy about the person, the stuff that you wouldn't already assume. Comments should do the same. A big help here, already mentioned by another replier, is commenting the what rather than the how, since knowing the what gives you a set of reasonable expectations.
A more concrete expression of this tip is to try to comment the data structures, not the algorithms. If you do a good job describing what your data is, then I'll be able to guess what most of your code is going to say without reading it. And the rest is what's worth commenting.
I am the same way, except the lighter the music is, the more it distracts me. I much prefer something like Nine Inch Nails -- anything that's noisy and sounds like utter crap is good. If I like the music, then I'll start paying attention to it instead of my code. Stuff I don't like is good for drowning out background noise. Vocals are bad unless they're so mangled I can't make out anything they're saying.
> Remember: Sun has GPL'd Star Office's source code. That means that everyone can peek at it and change it
I'm not disagreeing, but having access to source code isn't always what it's cracked up to be. I've looked at the OpenOffice code. I even spent the better part of a week trying to figure out how part of it worked so I could use it for my own stuff. And completely failed. It was a complete tangle, or at least the part I needed was. It was like "hey, object orientation is supposed to be powerful -- I bet we could really confuse the hell out of people with it!" Taking two hours to build on a 600MHz PIII didn't help much, either. And that's after you dig up the obsolete gcc version that it requires.
Mozilla code is much better. Perl code (as in, the C implementation of perl) seems as bad at first, but you can actually make steady progress if you try. Linux code is a gem in comparison. I've dug into several dozen projects, and OpenOffice is the worst that I can remember. (Admittedly, I usually give up early on the worst stuff when I don't *need* to be punishing myself.)
Slashdot Mirror
You're still using the original CPU that came with your computer? There's probably not much left of it by now. Lots of programs have CPU leaks. Sure, you can deal with it by restarting stuff over and over again, but you'll just have to keep doing it. It's a lot more convenient to just buy a bunch of extra CPUs and swap them in when the older ones get used up.
I've been buying them by the 6-pack at Fry's. It's much easier now that popular OSes support hot-swappable CPUs, though I'm never sure how long I'm supposed to put them in the toaster first.
(Btw, please file a bug. Or switch to a FF4 beta first to see if it still happens there. That may also may make it much easier to figure out whether it's a plugin, since they can run in another process in FF4.)
I love bashing the rich, Microsoft, and especially Ballmer as much as anyone but it's kind of hard to overlook the glaring logic error in the cynicism: whether or not that measure passed would have no effect on Ballmer's stock sales before the end of the year anyway. I suppose it would've looked a little worse if the measure passed and he immediately dumped a bunch of stock, but somehow I don't think that PR problem is worth the effort and expense.
Err... so you are taking a patient providing a guaranteed revenue stream from staving off a terminal illness, and replacing him/her with a patient with a possibility of providing a smaller revenue stream, maybe for a longer period if you're lucky?
And this is a patient who almost died and suffered through uncountable procedures and doctors and uncertainty, and you think they'll jump at the chance to play with even more pills and doctors? Everyone I know who has had a serious encounter with the medical establishment would do almost anything to avoid having anything to do with doctors again. And that includes dying. (Yes, it's anecdotal, but I have deceased family members in precisely this category.) Younger people especially may find the idea ludicrous, but the idea of living at all cost becomes far less appealing once you become personally acquainted with that cost.
No money for the drug companies, true.
But what about the other much-maligned member of the "health care" industry: insurance companies? They would save a ton of money if somebody came up with a proper cure. Not only would they not have to pay for the expensive last-ditch drugs for the currently incurable disease, but they wouldn't need to treat all of the complications that arise from late-stage terminal illness.
People would probably freak out if the "evil insurance industry" started to dabble in researching their own drugs and treatments, but they are the ones with the incentive. This whole idea was given to me by a friend of mine, who once suggested to a high-level insurance representative that they should be awarding bounties for cures. It makes a lot of sense, even though bounties are obviously limited in what activities they can support.
(Note: the quotation marks around "evil insurance industry" should not be taken to mean that I actually disagree with the label; personally, I find the insurance industry as it is currently set up to indeed be a systemic evil. I'd much rather they sold insurance for catastrophic health expenses, rather than being an integral part of the payment and approval process.)
Or pay kids twice as much and get double the benefit!
Better yet, don't bother with the other 95% and just pay the $500! You'd save billions!
You may argue that that isn't at all what you said, but your statement is equally ludicrous. You're trusting badly insufficient base data and going off and calculating meaningless resulting figures. Are you in marketing, by any chance?
Have you factored in whether the improvement is sustained, which wasn't tested in the study?
I would bet that removing the rewards would actually make these students do worse than they did before the study started. Have you factored in that possibility?
Has any learning actually increased, or just the test scores? They're nowhere close to being the same -- cheating, cramming, and test-taking strategies are just some of the obvious ways to inflate test scores while keeping learning (of the tested material) constant or declining.
Is there collateral damage? As in, do these students stop studying for any subject that they don't get paid for, or other things in their lives? Might need to factor that in.
I'm happy to see that MS bought 3DV. 3DV has been promising that their camera will be available at scale for years. I talked to them at GDC a year and a half ago. "It'll be out this summer." "Who's your manufacturer?" "Oh, we don't have one yet. We'll just get someone in Taiwan or China to do it. Manufacturers are a dime a dozen."
So are companies with unbuildable products. I had to resist the urge to laugh in his face -- they didn't have their sh*t together in February and they'd have product on the shelves in the summer? I pretty much gave up hope on them then.
Which is too bad. They have a nice product -- not as good as Tyzx or PrimeSense, but theoretically it could be far less expensive.
Don't think of the EyeToy. That's a simple 2D differencing system, and not a very good one. I actually think it's a good product overall -- not enough so that I'd bother to buy one, but you could have fun with the right content. The vision system could be done better even with the harsh constraints (working in just about anyone's living room is surprisingly difficult.) But 2D images are fundamentally limited.
A depth-sensing camera like the Z-Cam, Tyzx, or PrimeSense can pick out gestures in front of your body, it can measure direction and acceleration in 3D, and it can pick players out from the background far better.
At the same time, our intuition was (and our experience found) that trying to convert camera input into controller input is just a bad idea. You don't want this for playing Halo 3. You need games built for camera input. It's fun for more than games, too -- we prototyped some nifty photo, video, and 3D model interfaces.
One of our most eyecatching prototypes was a light saber game where you could slice through oncoming hordes of robots. The video is dark and not very well done, sorry.
It is not impossible to use a public terminal securely -- it's just another example of tunneling secure data over an insecure link. One thing that some reponses neglect is that for many applications, the data coming back is just as critical to keep secure as the data (passwords etc.) going in. Unless you want everyone reading your email and seeing your bank account balances and pictures of your cute naked children.
Of course, to tunnel over an insecure link, you need secure endpoints. The remote endpoint is easy; it can be your server or proxy or whatever. It sounds like the Blackdog is an example of something that can provide the local endpoint. All that is needed is something that encrypts outgoing data and decrypts incoming.
I suggest Pig Latin. You use your laptop/PDA/whatever normally, except you convert your password to pig latin and your home proxy server transforms all incoming text in the same way. Sure, that only works for text, but I have a brilliant idea for an image transformation that works on the same principle: you take every image, move the first column of pixels to the end, and add 13 to each of the RGB values in that column (modulo 256). I think it should be pretty much invulnerable to decryption by unwanted snoopers, because it combines the full security of pig latin with that of ROT13.
I plan to file for a patent and start up a company based on this technique. Anyone who would like to get in on this incredible opportunity now is encouraged to send me their seed investments in small unmarked bills. No need to put on your return address; I have another algorithm that I plan to use to infer the sender's contact info based purely on the rest of the packaging. So far it only accurately estimates the sender's intelligence level, but I'm sure that by the time you send me the cash, I'll have it working well enough that I'll be able to tell everything I need to know about you.
Most mammals can do it naturally when they're young, but the ability disappears almost completely with age. However, even older rats have been induced to regenerate limbs. There seems to be a critical level of nerve density required to trigger regeneration (actually, it looks like it might not be the nerves themselves, but rather the Schwann bodies surrounding the nerves). In mammals, the density is too low. Adding a very small DC current will cause certain cells to dedifferentiate into at least pluripotent stem cells, then redifferentiate to regenerate the lost tissues and structures. Well, that and creating an artificial neuroepidermal junction, which can be done surgically be rerouting the nerve. (In frogs, a non-mammal that cannot naturally regenerate except when young, the cells that revert to stem cells are red blood cells, oddly enough. Their red blood cells still have degenerate nuclei that can be reactivated. That seems to be a major reason why regeneration is so rare in mammals; our red blood cells don't have nuclei at all, and hence cannot be used. Fortunately, it appears that there are other cells floating about that will respond.)
Of course, until recently all of this flew completely in the face of conventional medical beliefs, so I should warn that I'm giving you the opinions of a crackpot. (A crackpot who published much of this work in journals like Nature, and whose work has been reproduced at least in part. But considering that researchers still don't seem to have caught up with his work from the 70s, I'm guessing he's still considered a crackpot.)
You, too, can read about this crazy crackpot's research in "The Body Electric", by Robert Becker and Gary Selden. And if you're interested in what I wrote above, you probably should, because I wrote from my memory of reading the book. So it's almost certain to be a horribly distorted version.
If you take a somewhat longer view, then you'll immediately see that the referenced study is obviously correct:
... (well, certain ones -- eg prostitution -- have different characteristics.)
Let's see, we have a new occupation, with nothing to build on, but lots of stuff that can be done (profitably). Then a ton of people will flood into it, and there will massive duplication of effort as everyone builds up the same little building blocks (some of them selling them to each other). If there are other people somewhere that could accomplish the same thing, then they will eventually start doing it too, and undercutting the original people. It will take longer if there is a higher barrier to entry (required education or equipment or whatever), but eventually economic pressure will win. Dams will always fail eventually.
At the same time, the shared infrastructure and knowledge base will gradually grow, and there will be less need for the bottom people who are all doing the same thing over and over again, and more need for the higher level people who can take larger pieces and use them to reach further. At the same time, no level in the hierarchy is ever likely to die out completely.
That describes where the software field is today, but it could be a description of nearly any occupation: building cars, digging holes, feeding people, making games,
I don't know whether the study is accurate as of today, but it'll be more true as time goes on.
So Roman is trying to propose an architectural change and Ingo is sidelining him? Well, he does propose one structural change and one mathematical one, which sums up to an architectural change, I suppose -- but either can be done independently of the other, on the current code base. The remaining changes are renaming a file, removing lots of comments, and removing some of the capabilities of the existing CFS (which are orthogonal to what Roman is working on.)
It certainly does not sound like Ingo secretly thinks that Roman's work just sucks, but he is unconvinced that Roman is attacking a particularly relevant problem. Roman is fixated on rounding errors, which Ingo feels are rarely relevant. Either of them could be correct for all I know.
Beyond that honest disagreement, which will have to be resolved with test cases, I have to say it's hard not to side with Ingo. Roman's work could clearly have been presented in a way that would have been much easier to both understand and integrate, but instead he chose to (among other things) copy one whole file and rename it rather than patching it. I've merged in enough messy third-party patches to recognize a situation where someone just can't be bothered to do all of the work needed when you are developing on a shared code base. Imagine that someone finds an off by one bug in your code: it should have been while (a = b), but you wrote while (a b). They send you a patch with that change along with reformatting all of your comments and re-indenting 80% of the code. Not helpful. Even if their version is prettier. (And if it is, then splitting it into two patches would get all of the advantages, at the cost of more work for the patch submitter.)
The bad students are going to skip all the lectures, zip through all of the podcasts just before an exam, and fail anyway. Without the podcasts, they'll show up for some of the lectures, cheat off of their friends during the assignments, get copies of the podcasts from the same friends, and fail anyway. So it doesn't matter for them either.
The lazy students -- which is 90% of them, but we won't count the ones that fall in either of the preceding categories -- will use the existence of the podcasts as an excuse to not show up to class, will try to sail through them just before exams, and will discover that they can't absorb that much that fast. Those are the ones you're worried about.
I disagree with the other posters who say that there is no issue. I am one of those lazy students. I ended up doing pretty well as an undergrad and then getting an MS from UC Berkeley. In other words, I am one of the people who did well in the absence of those podcasts, and therefore am exactly the sort of person you wouldn't want to do worse if they were available. And my attendance record wasn't exactly stellar to begin with. With the added temptation of postponing a class via a podcast, I suspect I would have royally botched things up. It would have been 100% my own fault, of course, but the whole point of a university is to establish an environment conducive to learning (if you'll forgive the excess syllables.)
For the most part, that means presenting readily available information in a form that students are likely to pick up on, and doing so within a structure that encourages them to do so -- rather than cater exclusively to their much stronger short-term urges to get laid, hang with friends, and catch some Zs. So if some part of the structure makes it less likely for students to learn, even if it's totally those students' fault, then it's not a good idea for the university to set it up that way.
Still, your authentication schemes sound like way overkill. I can think of a couple of possibilities:
1. Have regular homework assignments that use the information in the lectures. Any class for which this makes sense should be doing this anyway, and anyone who is blowing off the homework needn't be catered to.
Still, I can think of a lot of classes I've taken that were more project-focused, and it seems silly to change them around merely because of the existence of podcasts. So...
2. During each lecture, verbally give the code to access the next lecture. Alone, this just provides a little more incentive to keep up with things so you're not wading through a dozen lectures to get the one you really want, but you could also combine it with either of the next two.
3. Make the podcasts available for a limited time. Allow exceptions on a case-by-case basis. I don't think I'd really recommend this one. You might even create a black market for the things.
4. Require students to ask for them individually. Give them out freely whenever they do, even at the last minute. You can automate it, as long as the student knows that the professor can see exactly who they are and when they requested it. Require a written reason (ignored by the automation) for a little added push.
Personally, I'd go for #1 when applicable, #2 alone when not.
Or flip the problem on its head -- what if everyone were required (ok, requested) to listen to the podcasts before the lecture, and the lecture was a lot more interactive? You could pack in more material, the students are incented to view the podcasts so they're not completely lost during the "lecture", and you get a better mix of theory and (guided) practice. I'm not thinking of a Q&A/recitation/discussion session (or whatever your school calls them); I'm more thinking of specific, practical examples of the material covered.
And finding properly parallelizable problems.
Google's only real vulnerability is in the court of public opinion, so privacy issues are a big deal. For now, they can't go too far for fear of public backlash. Soon, they will be held in check only by their "don't be evil" mantra. But the more money and power that their storehouse of information can provide, the harder it will be to resist using that information in unscrupulous ways. In my experience, you just can't trust in someone else's personal integrity to safeguard your interests; either that integrity will crack under pressure, or the person will be swept aside and rendered irrelevant. (Especially if it's a public company...)
I'll end with a little scenario. Someone bombs a building. Google decides to help out, and tells the FBI who bought the needed materials and when, everyone those people know, what they've looked for on the web, and what time they've been awake for the last few years.
Okay, the last is a stretch -- but I bet if I plotted every Google search I made against time, you could at least get a feel for what hours I'm keeping.
And they'll report the same for all of the bomber's acquaintances and those acquaintances' acquaintances, one of whom happens to be you. But don't worry; I'm sure the FBI would delete all that information once they were done with that case.
And I find your comment to be a brilliant description of why so many people erroneously believe that slapping a GUI on something magically makes it easy to use. There is a common mythology about both CLIs and GUIs that ends up doing a disservice to both. The problem is that each of your points is accurate, but in many cases they miss the point.
The perception of the CLI partly suffers from its strengths -- speed and power for advanced users. This makes everyone assume that it is only useful for those users for whom speed and power are important, namely advanced users, and not for newbies. A consequence of that viewpoint is that development of CLI features has long ignored the newbie issues -- the original article's use of a 'man commands' is a great example of a simple necessity that is sorely lacking. People put a lot of effort into pruning down GUIs for newbies or specific tasks, but something like 'man commands' will always get rejected for a CLI because it is not comprehensive, or because it "dumbs down" the interface. Is a pocketknife without a chainsaw and ice cream making attachment any "dumber" than one with? No, it's just more tuned to a set of tasks.
In fact, the CLI has a completely different set of advantages for newbies. I have a fair amount of experience in teaching newbies to use computers for the first time, and there just is no contest -- they have *always* preferred the CLI for those tasks that it is appropriate. A large reason for that is Post-Its: if they can jot something down on a Post-It, they will be able to remember and comfortably incorporate it into their daily tasks. GUI tasks are just not very Post-It compatible. (Note that I am only talking about newbies here; personally, I think that the easiest path for people is to start with the CLI, migrate to the GUI, then go back to the CLI.)
The primary advantage of GUIs that I see is the display of the available options, and most CLIs are sorely lacking here. Except that it ends up not helping newbies much, because all those "intuitive" associations between icons/menus and commands are lost on the newbie. Geeks really have no idea how foreign many of the basic computer concepts are to inexperienced people. Icons, for example, are horrible -- even if the user can recognize what an icon is supposed to represent, that doesn't mean they will understand the difference between a mail program and a particular mail message. "Why should I click on the little picture of the envelope? I've already done that and read the message that came up; I want to read the new ones! Where are they?" The whole desktop metaphor is a large stretch for people -- a real desktop starts out empty, with perhaps some little bits of furniture intended for various purposes. The user chooses where to put things and how to arrange stuff. Compare that to a computer desktop which is more akin to the control panel of a nuclear reactor, all laid out and ready for... who? Well, clearly for whoever set it up that way, not the naive user! The mixture of documents and applications and tools (wastebasket etc.) means that even if the user began with a mental model of a desktop, it will be quickly violated when they put something in the trash can and a big window pops up and yells at them.
Today's GUIs are not created with the mindset of a space in which a user can perform whatever tasks he/she cares about. Instead, they try to instruct the user in the "proper" way of doing things. Wizards and dialog boxes are great, but they are also saying that you have to do things in a particular order and enter a bunch of information that you don't really care about (at least not yet). "Are you sure you meant to do that?" -- why, is there something wrong with doing that?
Anyway, to respond to specific points:
CLI=dialog? Yes, it is imperfect. But understandable -- if you ask somebody to do something, they may or may not tell you that they've done it, or show you what it looks like having done it.
Discoverability This is a weakness in CLI
God didn't create the universe. Well, He did, but not intentionally. God just wanted a beer. But you can't just create a beer floating in the middle of the void -- there's nothing satisfying about it. It would be like a book written by an illiterate person -- sure, he could put lots of black squiggles onto a bundle of pages that would vaguely look like a book, but it wouldn't mean anything.
So for a proper beer, God pretty much had to make up physics. I'm not just talking about the refinements needed to get it to foam just right -- I'm talking about the whole deal. After you drink some, there should be less left over, not more. Drinking a beer should not make you turn into beer yourself. Beers should not be smarter than the drinker. Well, not the first few, at least. The state of drinking beer needs to contrast with something, so the state of not drinking beer must also exist. In fact, that's where most of the world came from, because having the world exist in only two states (currently drinking beer/currently not drinking beer) just seemed too lame to a clever guy like God. Same idea for water and other liquids -- if He can drink beer, He really ought to be able to drink not-beer, just so He can say He chose the beer instead.
And then there's the whole question of origins. A beer is so much less interesting if it creates itself or just spontaneously comes into existence. A truly full-bodied beer needs a background, a character, a story. God went a little crazy with that, inventing those 'human' things with enough cleverness to invent stuff, curiousity to try things out, and a desperate need to get sloshed, smashed, trashed, and basically totally drucking funk. And all that cleverness and curiousity necessitated science. And dinosaur fossils. And religion. (God got a real kick when he realized he'd have to invent religion, I remember. Of course, he wasn't exactly sober by that time...)
Oh, and you know that bit about "...and on the 7th day He rested?" Purely an excuse to keep us from bothering Him during His hangover. We're still on the 7th day, see. I'm not even sure if He thought far enough ahead to make an 8th day. He was having some trouble with the notion of Time, and I recall Him saying something like "aw, screw it. Nobody's going to be drinking any beer at the speed of light anyway. I'll see you later -- I'm gonna go get wasted."
Try a little calculation: add together the salary paid to the animal trainer, the bribe money to pay off the SPCA, and of course the salary for the actor in the alien suit himself. Oh yeah, and his stuntman and the mechanical animal double. Subtract out the cost of 1000 hours on a render farm and half a dozen CG serfs. And don't forget the ego of a director who is tired of the actors getting all the credit.
You really can't help but cringe in those scenes in AOTC when Anakin is riding some beast (both in the field and in the gladiator arena). I mean, it's so obviously a CGI effect. It just doesn't move right.
I agree completely. I don't think there's been a movie mixing live action and CGI that hasn't made me squirm in my seat. It completely throws me out of the mood -- all that disbelief that was hovering suspended overhead suddenly comes crashing down. It's strange -- I can see the wires pulling CG characters around much more clearly than the wires attached to people who are flying around in all kinds of unbelievable directions.
But I disagree that CGI doesn't have a place in recreating creatures. There are a very small handful of scenes I've seen over the years where it really worked. They're pretty much all cases where the difference registered itself at some deep level as being very alien (instead of very fake.) It's a trip to watch something that moves almost like something I'm familiar with -- but not quite. Sends shivers up my spine.
But when it doesn't work, it really doesn't work. I don't understand why so many things make it to the screen when they just don't move right. The only explanation I can come up with is that you have to spend the time and money before you get to see whether it works, and by that time -- well, you've already spend the time and money.
It may not be a maintenance nightmare -- but it'll become one. Unless it is extremely simple or will only be worked on by one person, and in either of those cases, maintenance isn't a big concern anyway.
There are two problems: first, comments and code gradually diverge, no matter how well-disciplined the programmers are. Think of it this way: when you write code, you introduce bugs. Everyone does, no matter how good of a programmer they are. But those bugs have many ways of getting exposed and being fixed. Either the compiler will catch them, or the first run through the code will, or QA will. Now what's so different about comments? They are bound to contain bugs too. But the mechanisms for catching them (code reviews and the occasional poor sap who wanders through chasing after a bug) are much, much weaker. Result: buggy comments.
Second, the assumed significance of a comment drops proportionally to the density of comments. If there are too many comments, a reader will naturally tune them out. When you read a book and the writer introduces a new character, she'll never tell you that the new guy is a human being with two arms and two legs and more crotch hair than knee hair. She'll tell you what's noteworthy about the person, the stuff that you wouldn't already assume. Comments should do the same. A big help here, already mentioned by another replier, is commenting the what rather than the how, since knowing the what gives you a set of reasonable expectations.
A more concrete expression of this tip is to try to comment the data structures, not the algorithms. If you do a good job describing what your data is, then I'll be able to guess what most of your code is going to say without reading it. And the rest is what's worth commenting.
I am the same way, except the lighter the music is, the more it distracts me. I much prefer something like Nine Inch Nails -- anything that's noisy and sounds like utter crap is good. If I like the music, then I'll start paying attention to it instead of my code. Stuff I don't like is good for drowning out background noise. Vocals are bad unless they're so mangled I can't make out anything they're saying.
> Remember: Sun has GPL'd Star Office's source code. That means that everyone can peek at it and change it
I'm not disagreeing, but having access to source code isn't always what it's cracked up to be. I've looked at the OpenOffice code. I even spent the better part of a week trying to figure out how part of it worked so I could use it for my own stuff. And completely failed. It was a complete tangle, or at least the part I needed was. It was like "hey, object orientation is supposed to be powerful -- I bet we could really confuse the hell out of people with it!" Taking two hours to build on a 600MHz PIII didn't help much, either. And that's after you dig up the obsolete gcc version that it requires.
Mozilla code is much better. Perl code (as in, the C implementation of perl) seems as bad at first, but you can actually make steady progress if you try. Linux code is a gem in comparison. I've dug into several dozen projects, and OpenOffice is the worst that I can remember. (Admittedly, I usually give up early on the worst stuff when I don't *need* to be punishing myself.)