That animal game is crap. I gave it appropriate answers for 'kangaroo' and it didn't guess it.
The game is supposed to learn by getting people to tell it new questions, and so is only as good as the answers it's already been told about. But it's that learning ability which makes it interesting from a programming perspective.
I'm surprised magazines haven't tried using stereoscopic pictures. This is a really easy 3d trick anyone can do- simply take two pictures of a static object side by side with the camera pointing towards a certain object (make sure its the same object in each one!). Put them next to each other, then slowly cross your eyes until they merge.
That never ever worked for me. Different coloured glasses are what it takes for me to see reliable 3D from 2D printed material. (3D cinemas can use polarization, or could except I tend to watch films with my head at a slant...)
However, I have seen a 3D display which worked by projecting different images at different angles, so that you could see things without any glasses or other special stuff. It worked really well. This was with display technology that was hot stuff back in 1993 or '94, so I'm sure we can do better than that now.
It's better if it is. Fewer moving parts, much easier to see what's going on.
A pretty good one to start with is a number guessing game. Teaches about control structures, IO, state and validation of input. Go from there on to something like the Animal Game. You can use that to teach about decision trees and persistence. And that covers a very large fraction of the foundation of computing.
so we'll end up with a sub-prime computing crisis?
how can you bail out companies that fail to keep sufficient computing reserves in hand to cover their potential obligations?
Well, on one level that level of commoditization represents a rather large success, so I'd be happy enough.
What you will see will be a market economy in computing. Some providers will be cheap-and-cheerful bit-shifters, others will provide stronger guarantees and/or fancier service but cost more. The customers will vote with their money according to how much they value things. What is needed though is a better way to express contracts in electronic form so that customers properly know what they're getting and service vendors know which contracts to stop honoring first in a crunch.
Let there be diversity. Choice is good, especially if we can have software to help us sort through all the choices. By analogy, it's good that I've got a choice of airlines for going intercontinental, and I'm glad that there's travel agents to act on my behalf.
Except that the training required to learn this software is more expensive than the software. It would be cheaper to hire an engineer who had his own tools.
Not really. The top-end CFD codes are really very expensive indeed, and have "interesting" restrictions on use too. (I know of at least one that is considered to be a munition, being greatly useful for designing missile systems.)
It's like when your car breaks - it's cheaper to hire a mechanic than to rent diagnostic computers and other tools the mechanic has and learn about internal combustion engines and how to use the tools you rented.
Except that the focus is on renting to businesses, not consumers. While cloud computing can be made to work with consumers, you typically won't sell it to them "raw", but rather as packaged services that might be paid for directly or through advertising. This whole area of cloud-driven business models is very complex indeed.
Remember, the term "cloud computing" was coined by the clueless who didn't understand the chart's meaning, or he would have simply said "distributed computing".
I should warn you, I work in this field. Cloud computing is more about the space where SOA and grid computing meet, while distributed computing tends to be more about building clusters and stuff like that. The issue is that once you go over the size of a cluster, the overheads of messaging go up massively as you start having to take into account things like security and management (i.e. asshats of all varieties). This means as you move up to the cloud level of conceptual operation you've got to think in terms of breaking your overall processing in different ways. For example, if you were doing drug discovery, you might use a large high-availability cluster (possibly based off a SETI@home-like cycle scavenger) to do the initial search for candidates, and then you'd refine the matches with supercomputing time (using finer and more complex models of molecular interactions) where you know you're not just throwing effort away on a "no hope" option. And that is actually a simple example of what is going to be the case; science and engineering workflows can easily get much more complex, especially when working with multiple datasets with elaborate security requirements (common in medical research). And it's when you consider the effects of this on the way that software vendors work that the whole renting stuff drops out as a way of (probably) increasing the size of market for those guys.
In short, your cynicism is both understandable and laudable, but misplaced.
Its takes energy to make lime (CaO). You need to start with limestone (CaCO3) and drive off the CO2. Eventually the CaO added to the water will become limestone and precipitate out. There is no magic here.
Well, the suggestion is a crazy one indeed, but not because of the energy required to convert limestone to lime. The problem is that that process (how virtually all lime is produced) produces exactly as much CO2 as is then absorbed later on when you sling the stuff in the sea. After all, it's just the reverse reaction! You'd be better off just grinding up the limestone into fine dust and throwing it in the ocean directly; cheaper and just as effective (i.e. not very).
Now, if only the authors of the article had run it past someone with high school Chemistry, they'd have found out the flaw in their cunning plan...
'Cloud Computing' is just the latest marketing promotion designed to move us to renting software.
For some software that makes sense. Some apps cost an enormous amount to buy a copy of (no, MS Office isn't one of these!) and many smaller businesses don't need a copy continually. For example, a small engineering firm probably doesn't need a Computational Fluid Dynamics package the whole time, but when they're designing a product it's useful to rent some use of one.
Does this mean that everyone will be hiring everything? I really doubt it. I reckon that the end result will be a mixed economy with some purchases and some hiring. Which will be the dominant mode at any time? Well, that'll probably change from year to year. Guess what? That's true for other parts of the economy too. IT's not that special...
I also wonder if this took business users into account - I can't update because my IT department won't let me. I doubt that would be different if we were using Firefox or Opera rather than IE.
I've seen this come up a few times, and the code involved is usually something really horrible. (We have a leave booking system that doesn't really work with anything other than a specific sub-version of IE6 - the software we use was updated to support later versions, but we were too cheap to buy those updates. But our security people won out over our app support people, and IE6 got dropped. Lucky I guess. But I digress.) A nasty webapp is usually at heart of the problem, and yet chances are that some AJAX, or even a plain old HTML form, would do the job at least as well and work on more systems too.
Sounds to me like the best thing that the rest of us can do is to remove the explicit support for IE6 from our websites. When users complain, our reply can then be "Upgrade, lamers!" and then we just don't listen to their whining about corporate IT policies. After all, we could just say that we have a policy of not supporting ancient non-standards compliant rubbish. There's a limit, and bending over backwards to accommodate the broken won't make things better. It's time to do a bit of push-back.
Besides, how is the "else" getting "lost?" I mean, it's only two characters from the left margin! Saves lines too.
The only reason I can think of for not packing "else" tightly is when you're using an editor without syntax highlighting. But since I don't write code in Notepad.exe or classic/bin/vi, I don't care. Use your tools, folks!
My coding standards would completely ban the use of continue and only allow break in switch statements.
That coding style tend to end up with a complex nest of flag variables just so that you can signal the right sort of ending condition. Or maybe now that you've found what you were looking for you continue through that list just so that you can keep your loop condition simple? I've seen both in real code, and they don't make life easier. I prefer the solutions that keep code both short and shallow. (Well, as short and as shallow as possible given the algorithm needed at that point; if it needs 4 nested loops, so be it.)
Bah, it looks like you and I emphasize totally different things. Bet you're not an "80 column" guy...
Older compilers (and many current 8 bit) will generate a new stack frame for most nested levles of { where they couldn't tell if there was a new frame or not. Modern compilers see a much larger picture.
If by "older compilers" you are referring to stuff that's older than 15 years, then maybe. But I can assure you that for as long as I've been programming that's not been true. The compiler might extend the current stack frame's size, but that's not the same as creating a new one. As I said, you can tell this because you can still see the variables in the outer context (also stack-allocated) without trouble; if you were in a new stack frame, that would not work without special shenanigans.
I use these coding standards; they seem to work well in practice. Others are possible too, but I wouldn't get too hung up over minor differences; consistency is by far the most important aspect. It also helps if you've got documented pre- and post-conditions for all functions.
I've seen way too much code where a simple early return statement could have prevented insanely deep nesting which makes the code hard to understand, especially with inexperienced programmers who don't know how to simplify the logic.
That's an important observation that I've seen in a few places, and which also jibes with my experience. Whatever the length of your code, deeply nested code is bad news; it's much much harder to read than something that's functionally equivalent but shallow.
It doesn't help that most of that sort of deeply nested code tends to have lots of different flag variables all over the place to manage the redirection of the control flow from one deeply nested location to another. What the authors of such horrors have done is recreated spaghetti code using structured programming, but with even more complexity than the version with multiple exit points. Doesn't look like an overall win to me.
In my experience, good functions have conceptual integrity (they do one thing and do it properly) and are structured into four parts: checking preconditions, performing the changes, and cleaning up. The fourth part is a comment (usually at the front of the function) describing the intention of the function and its post-conditions. Early exit from the precondition check part is fine (though can require some cleanup sometimes) but once you start doing the real work, exit should only be through the cleanup part. The real work part should be as short as possible, but it's not as critical to keep the precondition checks short. (Cleanup length is usually not an issue; if it is, it probably needs factoring.)
The other really useful guideline I've seen is "be consistent and informative in variable name usage". It doesn't matter what the names are (except for 'i' and 'j', which had better be iterated indices) as long as they're consistently used; the goal is to make the code easier to understand at a glance.
So? He writes things up a lot better than most of the submissions. I have seen the Firehose, and Ye Gods! most of the stuff is badly written. If you want no more Roland, why not do some good (i.e. well written, informative) submissions yourself? It's not that hard, and you can pick a subject that you're an expert on.
Remember in C the {} does mean "create a new stack frame" as well as grouping.
Strictly no. It's a context, not a stack frame (since you can see the outer variables despite those not having file or global scope). What braces do is give you a lifetime for some variables, as well as a sequence of statements for which those variables are in scope for. In C, that's just a (good) convenience. In C++ it closely affects RAII lifetimes, and so is very important. (Alas, it's not always compiled as efficiently by C compilers as it perhaps ought to be, but that's a whole 'nother story.)
Real coders write code that you can take a ruler from any given close brace and draw a vertical line right up to the matching open brace, every time. Everybody else gets fired.
Lines are cheap. Time added trying to figure out an obfuscated code structure because somebody wanted to save lines (ie, put the open brace on the same line instead of doing the above) is expensive.
I prefer to put braces on the same line as the thing guarding them (if, for, while, etc.) and that works very nicely; I only have a "naked" brace when at the start of a function or for a bare block (occasionally useful). It's also like the style required by some other programming languages. But the point about lines being cheap is a good one. In particular, only ever put one statement per line since that makes debugging much easier. (Yeah, theoretically they could do sub-line error locating, but they don't.)
The other advantage with not putting on their own is that then you can see more lines on your screen at once. I like to have many things in view at once, and I've grown out of using 6pt fonts these days!
Nah. Surstromming. Anything that smells that bad and where the tins are inclined to explode (the wikipedia article claims that that's a myth, but that's just not true) is just a hazard waiting to happen...
Are your roads in order, is the traffic calm and orderly? Do you have electricity in your home? Are you being raided by armed bandits? what about clean water, can you drink the water coming out of your faucet? What about the mail, is it being delivered?
The classic example of a service that really is best being done by governments is a Fire Brigade. The problem with fire is that it spreads; if your neighbor's house is burning down, you want it to stop before it makes your own home go up in smoke too. Private fire brigades have been tried too (18th Century London IIRC) and were found to be massively sub-optimal; the brigades would turn up at all the fires about, but usually would either spend their time mocking the brigade with responsibility rather than helping, or even try to extort money out of the property owner in order to help. A public fire service (whether professional or amateur) is just much better overall. Public police services are a good idea for similar reasons: the vast majority of law-breakers are people you want to have punished for their crimes (whether or not the exact set of laws is correct or the punishments are correct is a separate matter) and it's better to have a public service for this rather than only having the very wealthy protected from crime by their private security forces.
Can things be fscked up? Sure. You've got to keep a close eye on governments to make sure that they are serving you and the people in general. But do without them? Only nutjobs are serious about that; ample evidence is that people just can't do without them (well, not while living at anything like the densities that they do at the moment).
For the rest of us, Royal Mail are now charging more, because they get less of the bulk mail to subsidise personal mail, and they are becoming much less reliable at delivering it.
The stupid thing is that the private post operators then hand off to the Royal Mail for letter delivery to private addresses, as the private operators don't have the staff to do that.
The saddest part is, more people will remember idiots like G. W. Bush than this man.
Too soon to tell if that'll really be the case. (Will Dubya be remembered as a monumental failure, or will he just be something for political historians? Will DeBakey be properly remembered for his achievements, or fall into obscurity and only mentioned to those in the medical profession? If both fall out of general knowledge, which will be more widely known?) Come back in another few hundred years, maybe a thousand, and we'll see.
Flash won't work on unapproved operating systems. Linux users don't care, because Linux is "approved". But it won't run on FreeBSD. But Linux users don't care because FreeBSD is not Linux.
Sounds like FreeBSD is on a winner there! Missing out on all those annoying adverts has got to be a positive...
Slashdot Mirror
>
You may now pelt me with taunts of "NERRRD!!".
Thank you for the permission.
"NERRRD!!"
That's better.
That animal game is crap. I gave it appropriate answers for 'kangaroo' and it didn't guess it.
The game is supposed to learn by getting people to tell it new questions, and so is only as good as the answers it's already been told about. But it's that learning ability which makes it interesting from a programming perspective.
I'm surprised magazines haven't tried using stereoscopic pictures. This is a really easy 3d trick anyone can do- simply take two pictures of a static object side by side with the camera pointing towards a certain object (make sure its the same object in each one!). Put them next to each other, then slowly cross your eyes until they merge.
That never ever worked for me. Different coloured glasses are what it takes for me to see reliable 3D from 2D printed material. (3D cinemas can use polarization, or could except I tend to watch films with my head at a slant...)
However, I have seen a 3D display which worked by projecting different images at different angles, so that you could see things without any glasses or other special stuff. It worked really well. This was with display technology that was hot stuff back in 1993 or '94, so I'm sure we can do better than that now.
Doesn't matter if it's a simple text game.
It's better if it is. Fewer moving parts, much easier to see what's going on.
A pretty good one to start with is a number guessing game. Teaches about control structures, IO, state and validation of input. Go from there on to something like the Animal Game. You can use that to teach about decision trees and persistence. And that covers a very large fraction of the foundation of computing.
so we'll end up with a sub-prime computing crisis?
how can you bail out companies that fail to keep sufficient computing reserves in hand to cover their potential obligations?
Well, on one level that level of commoditization represents a rather large success, so I'd be happy enough.
What you will see will be a market economy in computing. Some providers will be cheap-and-cheerful bit-shifters, others will provide stronger guarantees and/or fancier service but cost more. The customers will vote with their money according to how much they value things. What is needed though is a better way to express contracts in electronic form so that customers properly know what they're getting and service vendors know which contracts to stop honoring first in a crunch.
Let there be diversity. Choice is good, especially if we can have software to help us sort through all the choices. By analogy, it's good that I've got a choice of airlines for going intercontinental, and I'm glad that there's travel agents to act on my behalf.
Except that the training required to learn this software is more expensive than the software. It would be cheaper to hire an engineer who had his own tools.
Not really. The top-end CFD codes are really very expensive indeed, and have "interesting" restrictions on use too. (I know of at least one that is considered to be a munition, being greatly useful for designing missile systems.)
It's like when your car breaks - it's cheaper to hire a mechanic than to rent diagnostic computers and other tools the mechanic has and learn about internal combustion engines and how to use the tools you rented.
Except that the focus is on renting to businesses, not consumers. While cloud computing can be made to work with consumers, you typically won't sell it to them "raw", but rather as packaged services that might be paid for directly or through advertising. This whole area of cloud-driven business models is very complex indeed.
Remember, the term "cloud computing" was coined by the clueless who didn't understand the chart's meaning, or he would have simply said "distributed computing".
I should warn you, I work in this field. Cloud computing is more about the space where SOA and grid computing meet, while distributed computing tends to be more about building clusters and stuff like that. The issue is that once you go over the size of a cluster, the overheads of messaging go up massively as you start having to take into account things like security and management (i.e. asshats of all varieties). This means as you move up to the cloud level of conceptual operation you've got to think in terms of breaking your overall processing in different ways. For example, if you were doing drug discovery, you might use a large high-availability cluster (possibly based off a SETI@home-like cycle scavenger) to do the initial search for candidates, and then you'd refine the matches with supercomputing time (using finer and more complex models of molecular interactions) where you know you're not just throwing effort away on a "no hope" option. And that is actually a simple example of what is going to be the case; science and engineering workflows can easily get much more complex, especially when working with multiple datasets with elaborate security requirements (common in medical research). And it's when you consider the effects of this on the way that software vendors work that the whole renting stuff drops out as a way of (probably) increasing the size of market for those guys.
In short, your cynicism is both understandable and laudable, but misplaced.
Its takes energy to make lime (CaO). You need to start with limestone (CaCO3) and drive off the CO2. Eventually the CaO added to the water will become limestone and precipitate out. There is no magic here.
Well, the suggestion is a crazy one indeed, but not because of the energy required to convert limestone to lime. The problem is that that process (how virtually all lime is produced) produces exactly as much CO2 as is then absorbed later on when you sling the stuff in the sea. After all, it's just the reverse reaction! You'd be better off just grinding up the limestone into fine dust and throwing it in the ocean directly; cheaper and just as effective (i.e. not very).
Now, if only the authors of the article had run it past someone with high school Chemistry, they'd have found out the flaw in their cunning plan...
'Cloud Computing' is just the latest marketing promotion designed to move us to renting software.
For some software that makes sense. Some apps cost an enormous amount to buy a copy of (no, MS Office isn't one of these!) and many smaller businesses don't need a copy continually. For example, a small engineering firm probably doesn't need a Computational Fluid Dynamics package the whole time, but when they're designing a product it's useful to rent some use of one.
Does this mean that everyone will be hiring everything? I really doubt it. I reckon that the end result will be a mixed economy with some purchases and some hiring. Which will be the dominant mode at any time? Well, that'll probably change from year to year. Guess what? That's true for other parts of the economy too. IT's not that special...
I also wonder if this took business users into account - I can't update because my IT department won't let me. I doubt that would be different if we were using Firefox or Opera rather than IE.
I've seen this come up a few times, and the code involved is usually something really horrible. (We have a leave booking system that doesn't really work with anything other than a specific sub-version of IE6 - the software we use was updated to support later versions, but we were too cheap to buy those updates. But our security people won out over our app support people, and IE6 got dropped. Lucky I guess. But I digress.) A nasty webapp is usually at heart of the problem, and yet chances are that some AJAX, or even a plain old HTML form, would do the job at least as well and work on more systems too.
Sounds to me like the best thing that the rest of us can do is to remove the explicit support for IE6 from our websites. When users complain, our reply can then be "Upgrade, lamers!" and then we just don't listen to their whining about corporate IT policies. After all, we could just say that we have a policy of not supporting ancient non-standards compliant rubbish. There's a limit, and bending over backwards to accommodate the broken won't make things better. It's time to do a bit of push-back.
Besides, how is the "else" getting "lost?" I mean, it's only two characters from the left margin! Saves lines too.
The only reason I can think of for not packing "else" tightly is when you're using an editor without syntax highlighting. But since I don't write code in Notepad.exe or classic /bin/vi, I don't care. Use your tools, folks!
My coding standards would completely ban the use of continue and only allow break in switch statements.
That coding style tend to end up with a complex nest of flag variables just so that you can signal the right sort of ending condition. Or maybe now that you've found what you were looking for you continue through that list just so that you can keep your loop condition simple? I've seen both in real code, and they don't make life easier. I prefer the solutions that keep code both short and shallow. (Well, as short and as shallow as possible given the algorithm needed at that point; if it needs 4 nested loops, so be it.)
Bah, it looks like you and I emphasize totally different things. Bet you're not an "80 column" guy...
Older compilers (and many current 8 bit) will generate a new stack frame for most nested levles of { where they couldn't tell if there was a new frame or not. Modern compilers see a much larger picture.
If by "older compilers" you are referring to stuff that's older than 15 years, then maybe. But I can assure you that for as long as I've been programming that's not been true. The compiler might extend the current stack frame's size, but that's not the same as creating a new one. As I said, you can tell this because you can still see the variables in the outer context (also stack-allocated) without trouble; if you were in a new stack frame, that would not work without special shenanigans.
Speaking as a brit who doesn't like travelling into the prison state any more, I can't see myself attending any large events which are US only.
You mean returning to your prison state right?
You forget, you've got the TSA.
I use these coding standards; they seem to work well in practice. Others are possible too, but I wouldn't get too hung up over minor differences; consistency is by far the most important aspect. It also helps if you've got documented pre- and post-conditions for all functions.
I've seen way too much code where a simple early return statement could have prevented insanely deep nesting which makes the code hard to understand, especially with inexperienced programmers who don't know how to simplify the logic.
That's an important observation that I've seen in a few places, and which also jibes with my experience. Whatever the length of your code, deeply nested code is bad news; it's much much harder to read than something that's functionally equivalent but shallow.
It doesn't help that most of that sort of deeply nested code tends to have lots of different flag variables all over the place to manage the redirection of the control flow from one deeply nested location to another. What the authors of such horrors have done is recreated spaghetti code using structured programming, but with even more complexity than the version with multiple exit points. Doesn't look like an overall win to me.
In my experience, good functions have conceptual integrity (they do one thing and do it properly) and are structured into four parts: checking preconditions, performing the changes, and cleaning up. The fourth part is a comment (usually at the front of the function) describing the intention of the function and its post-conditions. Early exit from the precondition check part is fine (though can require some cleanup sometimes) but once you start doing the real work, exit should only be through the cleanup part. The real work part should be as short as possible, but it's not as critical to keep the precondition checks short. (Cleanup length is usually not an issue; if it is, it probably needs factoring.)
The other really useful guideline I've seen is "be consistent and informative in variable name usage". It doesn't matter what the names are (except for 'i' and 'j', which had better be iterated indices) as long as they're consistently used; the goal is to make the code easier to understand at a glance.
It's so Roland the Plogger.
So? He writes things up a lot better than most of the submissions. I have seen the Firehose, and Ye Gods! most of the stuff is badly written. If you want no more Roland, why not do some good (i.e. well written, informative) submissions yourself? It's not that hard, and you can pick a subject that you're an expert on.
Remember in C the {} does mean "create a new stack frame" as well as grouping.
Strictly no. It's a context, not a stack frame (since you can see the outer variables despite those not having file or global scope). What braces do is give you a lifetime for some variables, as well as a sequence of statements for which those variables are in scope for. In C, that's just a (good) convenience. In C++ it closely affects RAII lifetimes, and so is very important. (Alas, it's not always compiled as efficiently by C compilers as it perhaps ought to be, but that's a whole 'nother story.)
Real coders write code that you can take a ruler from any given close brace and draw a vertical line right up to the matching open brace, every time. Everybody else gets fired.
Lines are cheap. Time added trying to figure out an obfuscated code structure because somebody wanted to save lines (ie, put the open brace on the same line instead of doing the above) is expensive.
I prefer to put braces on the same line as the thing guarding them (if, for, while, etc.) and that works very nicely; I only have a "naked" brace when at the start of a function or for a bare block (occasionally useful). It's also like the style required by some other programming languages. But the point about lines being cheap is a good one. In particular, only ever put one statement per line since that makes debugging much easier. (Yeah, theoretically they could do sub-line error locating, but they don't.)
The other advantage with not putting on their own is that then you can see more lines on your screen at once. I like to have many things in view at once, and I've grown out of using 6pt fonts these days!
one word: lutefisk
Nah. Surstromming. Anything that smells that bad and where the tins are inclined to explode (the wikipedia article claims that that's a myth, but that's just not true) is just a hazard waiting to happen...
Are your roads in order, is the traffic calm and orderly? Do you have electricity in your home? Are you being raided by armed bandits? what about clean water, can you drink the water coming out of your faucet? What about the mail, is it being delivered?
The classic example of a service that really is best being done by governments is a Fire Brigade. The problem with fire is that it spreads; if your neighbor's house is burning down, you want it to stop before it makes your own home go up in smoke too. Private fire brigades have been tried too (18th Century London IIRC) and were found to be massively sub-optimal; the brigades would turn up at all the fires about, but usually would either spend their time mocking the brigade with responsibility rather than helping, or even try to extort money out of the property owner in order to help. A public fire service (whether professional or amateur) is just much better overall. Public police services are a good idea for similar reasons: the vast majority of law-breakers are people you want to have punished for their crimes (whether or not the exact set of laws is correct or the punishments are correct is a separate matter) and it's better to have a public service for this rather than only having the very wealthy protected from crime by their private security forces.
Can things be fscked up? Sure. You've got to keep a close eye on governments to make sure that they are serving you and the people in general. But do without them? Only nutjobs are serious about that; ample evidence is that people just can't do without them (well, not while living at anything like the densities that they do at the moment).
For the rest of us, Royal Mail are now charging more, because they get less of the bulk mail to subsidise personal mail, and they are becoming much less reliable at delivering it.
The stupid thing is that the private post operators then hand off to the Royal Mail for letter delivery to private addresses, as the private operators don't have the staff to do that.
thankfully they have no plans to migrate to IPv6
That's a good thing, you know. Explaining to them why they have to migrate to IPvMany might take a while...
Pluto does not have rings.
But he does have a green collar.
The saddest part is, more people will remember idiots like G. W. Bush than this man.
Too soon to tell if that'll really be the case. (Will Dubya be remembered as a monumental failure, or will he just be something for political historians? Will DeBakey be properly remembered for his achievements, or fall into obscurity and only mentioned to those in the medical profession? If both fall out of general knowledge, which will be more widely known?) Come back in another few hundred years, maybe a thousand, and we'll see.
Flash won't work on unapproved operating systems. Linux users don't care, because Linux is "approved". But it won't run on FreeBSD. But Linux users don't care because FreeBSD is not Linux.
Sounds like FreeBSD is on a winner there! Missing out on all those annoying adverts has got to be a positive...