SiO2 particles have a half-life of a hillion-jillion years, but they don't worry me. Time of exposure is only half the story, and besides, no living being is going to be exposed to radioactive material for millions of years.
One atom of U235 doesn't worry me. As the same amount of material is spread more and more thinly, there comes a point at which the dose for any individual is so small that he's very likely to die of age before it makes any significant difference. The damage is proportional, not just to length of exposure, but also to intensity of radiation, which is proportional to the amount of radiating stuff per unit volume. People didn't die instantly when they bought pottery glazed with uranium pigments; I honestly don't know whether anybody has shown significant health effects from long-term exposure to uranium-glazed dinnerware.
One difficulty in teaching the more structured development models is that you need a *big* project to really feel in your gut that this stuff is necessary. Most courses just don't have the time to do big projects, so the class sit there thinking that what they're learning is overkill for anything they've done.
I'm reading up on some of this stuff right now, and half the time I find myself thinking, "yes, that looks useful, but not on any of the tiny projects I get."
Code with personal annotations shouldn't be *released*, but it's good in the interim. For example, early on I tend to write a lot of/* FIXME xxx */ comments so I can get the basic idea into working order and then go back and think about the corner cases without a lot of other concerns swimming 'round in my head. The module is not ready until all of the FIXMEs have been replaced with code which no longer makes me want to write FIXME. Sometimes a FIXME marks a stub that will be replaced with a sizable code block, but which serves to have something runnable for checking out the rest of the function.
A *release* is like a finished building, but development versions are more like a construction site: there's mud and mess and temporary make-dos everywhere (all of which will be cleared away before the building is presented to its owner), and that's not a problem.
One of the things I used to like about DEC's Language Sensitive Editor, when I had access to such tools, was that it encouraged this style of development. There were built-in commands to open a pseudocode block, to skip to the next block, and to turn a block into a proper comment for the chosen programming language and position you beneath it to fill in the code. LSE took a bit of learning beyond the usual text editor, but after that it was quite pleasant to work with. I miss it.
There's probably a way to do this in Emacs (there's a way to do everything *else* ever invented, in Emacs) but I haven't found it yet.
Yes indeedy. Keeping track of versions as the code changes is a mechanical process, so have the machine do it for you. Keep your brainpower for the creative stuff that we don't know how to automate.
An awful lot of poor systems and poor results can be attributed to making machines do what humans do better and vice versa.
"We comment all functions and classes using the Doxygen format. This means that the comments can be used to generate HTML, PDF or man pages for the functions and classes."
Good for you. This means you can often just copy the material from the design documents when you begin building the code.
Just because you understand your code today does not mean you'll remember why you did it that way six years, or even six months, from now. It's happened to you. It's happened to me, too, and to lots of others.
Notice that in the tech books filled with big slabs of code, code crafted *specifically* to teach the reader, the author still has to explain, sometimes at considerable length, what the code does and why it does it that way.
Poor commentary is a waste of time -- it only tells you what the code tells you. This is true. But good commentary tells you things that cannot be expressed in the code. Things you'll need to know if you want to repair or recast or reuse the code.
But aside from that, writing good, durable commentary helps you to build better code in the first place, by making you think twice, in two different ways, about what you are doing. I wish I could recall specific examples, but I'm sure that more than once I've saved myself from error when I looked at the comments I wrote and said, "that's nonsense -- what is really going on here?"
I'll accept your numbers for now, but we must also bear in mind that the U coming out of a smokestack is much more evenly distributed in space and time than the sudden eruption of relatively larger particles from a worst-case reactor breach. Spreading the stuff across a million km^2 over 30 years is a bit different from spewing 1/10 that amount over a thousand km^2 in an hour.
I agree that nuclear power isn't inevitably disastrous or even (when well run, which it sometimes isn't) inherently more harmful than any other way we have of releasing energy, but the raw numbers can be as misleading as raw fear. Carelessness with a nuke plant *can* cause a much worse mess than carelessness with a coal plant. Let's use nuclear energy, but let's also be careful in proportion to our ability to screw up really bigtime with that kind of power.
I hadn't noticed that they intend to leave the thing in Earth orbit very long either. You don't get to Callisto that way.
The whole thing is designed to go far, far away and not come back. Exactly what a lot of people would like to see happen to all radioactive material, near as I can tell.
"They have a Pentium-90 driving (pointing) their main 'scope with a backup P-90 literally sitting on the next shelf in case it dies."
That's actually rather good provisioning. A P-90 as a motor controller is probably 99% idle even when it's moving things, and you'd want redundant gear anyway because, hey, even brand-new equipment fails and scope time is hideously valuable.
I was being somewhat facetious -- I can't name a pocket calculator that's known to run Apache, although doubtless someone's tried it on a sufficiently husky palmtop. But you've seen that kind of "study" -- like the one that proved that it costs more to run Linux than Windows if you buy a PeeCee to run Windows and an AS/400 to run Linux.
It's probably somewhat related to the one-tool-fits-all approach which is so widely practiced. Every week I see people use spreadsheet tools to emulate DBMSs, do something resembling graphic design, or more or less replace a notepad. Some of these are good attempts, some mighty poor ones, and some leave one wondering whether to laugh or weep.
...the manufacturers would wake up and actually make some DTV sets, or even DTV converters. I go looking for them every once in a while. I never see any. I see lots of "digital-*ready*" gear, but that just means there's a high-speed analog input to connect to the box I've never found.
I'd probably own a DTV converter by now, if I could find one in the store, and it didn't cost more than a complete 27" analog receiver. Many of us aren't switching because we *can't*.
"What kind of server do you have that requires [realtime AV]?"
File servers. You know, machines whose sole purpose is for end-users to stow files on them.
If your end users are keeping all of their critical files on their workstations you need to fire your admins and get some new ones who have a clue about disaster recovery.
If it was like most of those studies, more likely the difference was due to a finely-tuned IIS running on a 4-way Xeon vs. Apache right out of the box running on a pocket calculator with half its memory disabled.
It sounds like they are two different companies, which makes it somewhat likely that they run different AV products. But all of this is guesswork; let's wait for the facts.
After Christmas, wouldn't it be nice to just pull up the covers and sleep 'til Easter? Sure, I'd be sleeping away a couple of months of my life every year, but I'll bet I'd get it all back by avoiding the wear and tear due to shoveling snow (and the stress from chewing on curses aimed at the snow I have to shovel.)
I hadn't noticed. Someone else at work noted that their flagship products are complementary, and I'd have to agree. I mean, Acrobat is useful, while Shockwave and Flash...ahem...I mean, Adobe is all about sticking things precisely in place, while Macromedia's forte has been getting them to fly around. Documents vs. movies. Substance vs. style, in my view.
I can't figure out what they patented. Is it the concept of querying a database and displaying the results in a form? That's what the text sounds like. Or is it Apple's dream keyboard (the one you have to click with the mouse in order to type)?
Either way it sounds much more cumbersome, error-prone, and generally distressing than "seize a telephone; press 9, 1, 1; tell the dispatcher what your problem is."
I just get so tired of reading about "mergers" where A swallows B whole. That's not a merger. But the concept has now been so badly polluted that Adobe has to announce that its name is not changing just because it acquired Macromedia. I would have been surprised if they *had* changed their name.
Slashdot Mirror
Indeed, I don't care who runs it so long as it's fully documented so we can plug it into a metasearch framework alongside Google and others.
SiO2 particles have a half-life of a hillion-jillion years, but they don't worry me. Time of exposure is only half the story, and besides, no living being is going to be exposed to radioactive material for millions of years.
One atom of U235 doesn't worry me. As the same amount of material is spread more and more thinly, there comes a point at which the dose for any individual is so small that he's very likely to die of age before it makes any significant difference. The damage is proportional, not just to length of exposure, but also to intensity of radiation, which is proportional to the amount of radiating stuff per unit volume. People didn't die instantly when they bought pottery glazed with uranium pigments; I honestly don't know whether anybody has shown significant health effects from long-term exposure to uranium-glazed dinnerware.
One difficulty in teaching the more structured development models is that you need a *big* project to really feel in your gut that this stuff is necessary. Most courses just don't have the time to do big projects, so the class sit there thinking that what they're learning is overkill for anything they've done.
I'm reading up on some of this stuff right now, and half the time I find myself thinking, "yes, that looks useful, but not on any of the tiny projects I get."
Code with personal annotations shouldn't be *released*, but it's good in the interim. For example, early on I tend to write a lot of /* FIXME xxx */ comments so I can get the basic idea into working order and then go back and think about the corner cases without a lot of other concerns swimming 'round in my head. The module is not ready until all of the FIXMEs have been replaced with code which no longer makes me want to write FIXME. Sometimes a FIXME marks a stub that will be replaced with a sizable code block, but which serves to have something runnable for checking out the rest of the function.
A *release* is like a finished building, but development versions are more like a construction site: there's mud and mess and temporary make-dos everywhere (all of which will be cleared away before the building is presented to its owner), and that's not a problem.
One of the things I used to like about DEC's Language Sensitive Editor, when I had access to such tools, was that it encouraged this style of development. There were built-in commands to open a pseudocode block, to skip to the next block, and to turn a block into a proper comment for the chosen programming language and position you beneath it to fill in the code. LSE took a bit of learning beyond the usual text editor, but after that it was quite pleasant to work with. I miss it.
There's probably a way to do this in Emacs (there's a way to do everything *else* ever invented, in Emacs) but I haven't found it yet.
Yes indeedy. Keeping track of versions as the code changes is a mechanical process, so have the machine do it for you. Keep your brainpower for the creative stuff that we don't know how to automate.
An awful lot of poor systems and poor results can be attributed to making machines do what humans do better and vice versa.
"We comment all functions and classes using the Doxygen format. This means that the comments can be used to generate HTML, PDF or man pages for the functions and classes."
Good for you. This means you can often just copy the material from the design documents when you begin building the code.
Why are you looking at me that way?
Just because you understand your code today does not mean you'll remember why you did it that way six years, or even six months, from now. It's happened to you. It's happened to me, too, and to lots of others.
Notice that in the tech books filled with big slabs of code, code crafted *specifically* to teach the reader, the author still has to explain, sometimes at considerable length, what the code does and why it does it that way.
Poor commentary is a waste of time -- it only tells you what the code tells you. This is true. But good commentary tells you things that cannot be expressed in the code. Things you'll need to know if you want to repair or recast or reuse the code.
But aside from that, writing good, durable commentary helps you to build better code in the first place, by making you think twice, in two different ways, about what you are doing. I wish I could recall specific examples, but I'm sure that more than once I've saved myself from error when I looked at the comments I wrote and said, "that's nonsense -- what is really going on here?"
I'll accept your numbers for now, but we must also bear in mind that the U coming out of a smokestack is much more evenly distributed in space and time than the sudden eruption of relatively larger particles from a worst-case reactor breach. Spreading the stuff across a million km^2 over 30 years is a bit different from spewing 1/10 that amount over a thousand km^2 in an hour.
I agree that nuclear power isn't inevitably disastrous or even (when well run, which it sometimes isn't) inherently more harmful than any other way we have of releasing energy, but the raw numbers can be as misleading as raw fear. Carelessness with a nuke plant *can* cause a much worse mess than carelessness with a coal plant. Let's use nuclear energy, but let's also be careful in proportion to our ability to screw up really bigtime with that kind of power.
I hadn't noticed that they intend to leave the thing in Earth orbit very long either. You don't get to Callisto that way.
The whole thing is designed to go far, far away and not come back. Exactly what a lot of people would like to see happen to all radioactive material, near as I can tell.
That's okay; he also misspelled "Kazakhstan", so it balances out. :-)
"They have a Pentium-90 driving (pointing) their main 'scope with a backup P-90 literally sitting on the next shelf in case it dies."
That's actually rather good provisioning. A P-90 as a motor controller is probably 99% idle even when it's moving things, and you'd want redundant gear anyway because, hey, even brand-new equipment fails and scope time is hideously valuable.
I was being somewhat facetious -- I can't name a pocket calculator that's known to run Apache, although doubtless someone's tried it on a sufficiently husky palmtop. But you've seen that kind of "study" -- like the one that proved that it costs more to run Linux than Windows if you buy a PeeCee to run Windows and an AS/400 to run Linux.
It's probably somewhat related to the one-tool-fits-all approach which is so widely practiced. Every week I see people use spreadsheet tools to emulate DBMSs, do something resembling graphic design, or more or less replace a notepad. Some of these are good attempts, some mighty poor ones, and some leave one wondering whether to laugh or weep.
...the manufacturers would wake up and actually make some DTV sets, or even DTV converters. I go looking for them every once in a while. I never see any. I see lots of "digital-*ready*" gear, but that just means there's a high-speed analog input to connect to the box I've never found.
I'd probably own a DTV converter by now, if I could find one in the store, and it didn't cost more than a complete 27" analog receiver. Many of us aren't switching because we *can't*.
"What kind of server do you have that requires [realtime AV]?"
File servers. You know, machines whose sole purpose is for end-users to stow files on them.
If your end users are keeping all of their critical files on their workstations you need to fire your admins and get some new ones who have a clue about disaster recovery.
If it was like most of those studies, more likely the difference was due to a finely-tuned IIS running on a 4-way Xeon vs. Apache right out of the box running on a pocket calculator with half its memory disabled.
It sounds like they are two different companies, which makes it somewhat likely that they run different AV products. But all of this is guesswork; let's wait for the facts.
...so long as he doesn't infringe my patent on Improvement in Method of Leaving Things Well Enough Alone.
After Christmas, wouldn't it be nice to just pull up the covers and sleep 'til Easter? Sure, I'd be sleeping away a couple of months of my life every year, but I'll bet I'd get it all back by avoiding the wear and tear due to shoveling snow (and the stress from chewing on curses aimed at the snow I have to shovel.)
I hadn't noticed. Someone else at work noted that their flagship products are complementary, and I'd have to agree. I mean, Acrobat is useful, while Shockwave and Flash...ahem...I mean, Adobe is all about sticking things precisely in place, while Macromedia's forte has been getting them to fly around. Documents vs. movies. Substance vs. style, in my view.
I can't figure out what they patented. Is it the concept of querying a database and displaying the results in a form? That's what the text sounds like. Or is it Apple's dream keyboard (the one you have to click with the mouse in order to type)?
Either way it sounds much more cumbersome, error-prone, and generally distressing than "seize a telephone; press 9, 1, 1; tell the dispatcher what your problem is."
I just get so tired of reading about "mergers" where A swallows B whole. That's not a merger. But the concept has now been so badly polluted that Adobe has to announce that its name is not changing just because it acquired Macromedia. I would have been surprised if they *had* changed their name.
The important thing is that it's juuuust big enough for Longhorn. :-}
Buy your parts from brands you know you can trust?
I bought white-box memory *once*. Never again. It ran okay on day 1 but died in a few months.