I'm not sure that I've ever seen the terms "orbital" and "price-competitive" in the same paragraph before.
It costs BILLIONS to build a large electrical plant and its related infrastructure. That makes some rather expensive efforts competitive.
Consider a steam plant in orbit. Fuel is free: Sunlight at over 6 times the intensity at the earth's surface, 24/7. Collectors and radiators are feather-light because they don't have to fight gravity or be protected from oxidation, dirt, and mositure. Ditto for the downlink antennas. The actual generation mechanism is pretty small and so can be reasonably light. Downlink transmitters are moderately big - but they're just integrated circuits and/or IC/vacuum tube hybrids (with lots of high-quality vacuum available). Ground structure is a few acres of desert or pasture with a rather open antenna structure over it, and a small building for the DC/AC conversion and pilot transmitter. (You can graze cattle under it if it's pasture, desert life won't be bothered once construction is done - and it will find more shelter among the structures.)
Build the station in low orbit and it can power its own ion engines to move itself up to its final synchronous-orbit site.
Compare that to moving mountains to build a plant on the ground and more to dig up fuel and transport it, building stacks and pollution filters, disposing of scrubbed ash and acids, buying land for the site and the railroad or pipeline to feed it, making everything strong enough to resist gravity, protesters, and sabateurs.
You can afford a LOT of launches, even of the shuttle, with a budget like that.
Far from the impact crater a *lot* of vegetation survived - this is what destroyed earlier theories about a worldwide fire (it was actually quite localized).
Are we back to nuclear winter (like) theories? Now I'm really confused.
I was under the impression that the nuclear winter theories were the old ones, and that they were very recently supplanted by the global fire scenario. This happened when some physicists started wondering what would happen to all the debris kicked up by the impact, did some calculations, and came to the conslusion that they would go out of the atmosphere and then rain down all over the planet - turning the sky into the equivalant of the inside of a broiler oven for several hours, dessicating plants and starting the fires worldwide. Global forest/grass fires would then kill off everyting that wasn't in an underground shelter or underwater when the sky lit up. (Afterward there'd be lots of starvation, pollution, and the like. But first there was the accute broiling of everything above ground.)
This was then compared to the surviving critter mix, and it was observed that on one side of the planet the survivors were largely nocturnal burrowers and on the other side they were diurnal, leading to an estimate of the time of day of the impact. Also: Lots of fire ash was found, worldwide, at the C-T boundary along with the irridium.
A fire scenario would account for the survival of the bees. Hives in rock-sheltered locations wouldn't be subject to burnout. The reproductive members of the hive would be IN the hive, and would stay in through the fire. Within a year or less, flowering weeds would regrow from taproots and begin feeding the hive (which can survive for a LONG time - several years - on its stored honey and pollen.)
Are you saying that this relatively recent scenario was debunked, and they're back to "nuclear winter"?
No, the dance theory has to do with how a forager bee tells the rest of the workers precicely where the food is that he found. The legend goes that he first spins one way X times to denote the direction, then the other way X times to denote the distance.
The descriptions of the "waggle dance" I've seen don't match the one you give. They're more like this:
The dancing forager bee does a figure-8 path around a slashed-circle - like the capital leter theta. The straight run is what's significant.
The angle of the striaght run with the vertical is the same as the angle between the sun and the path to the food. The bee waggles its butt while on the straight path, and the number of waggles is proportional to the flight effort to get to the food under prevailing wind conditions.
The surrounding bees observe the dance, pick up the scent of the food source off the dancing bee, then take off BEFORE it goes out for another load.
I hear Intel is integrating WiMAX into a chip to go on the laptop motherboard - and that this chip/core/whatever is also capable of WiFi.
WiFi(b, g) could be viewed as a slightly degraded version of the OFDM/OFDMA PHYs of WiMAX, operating just adjacent to one of WiMAX's several bands, with a somewhat different MAC. So it's easy to do with the same hardware. The DSP has more than enough capacity and runs much the same algorithms, the radio can tune the band, and the MAC logic is related but simpler, and well-debugged. 802.11a isn't that much different either, and also in range of the radio. So once you have working designs for each it's pretty trivial to do both WiMAX and WiFI in the same chip (at least if you're not trying to do them at the same time).
Perhaps this release thrash is related to that.
What I want to know is when WiMAX becomes a standard part of the laptop support chip line.
Unfortunately, the radical greens have shot down the only really viable means for radically reducing CO2 output, nuclear power.
Actually there are (at least) two others. But I'm sure the eco-fascists (not to be confused with actual environmental scientists) would be opposed to them as well.
One is space solar power: Orbital solar collectors and milimeter-wave downlink to rectennas. It's actually price-competitive with fossil fuel plants (despite a flawed NASA study) and will get moreso with the development of private orbital capacity. (Bullshit about birds cooked in flight has already been issued.)
The other is to seed the South Pacific with a bit of iron compounds so the algae bloom will suck down megatons of CO2 and sequester it in the deep ocean for time measured in kiloyears, and continue with fossil fuel until, say, the necessary fusion breakthroughs occur or the eventual price rises make other alternatives attractive.
It seems odd to see them whine on one hand about too much CO2, and then whine on the other hand that people would *gasp* actually consider using a CO2 free source of electricity.
These heavily charged extremely small particles have the property that they change the capacitance of parts of semiconductors when passed through them.
Close but no cigar.
The rapid passage of a charged particle deposits enough energy on nearby charged particles to jog them out of place - creating a sudden conductive sea of electron-hole pairs. These charge carriers are then swept away by the local field, becoming a burst of current.
This affects memory and logic devices in two ways:
1) It can suddenly leak away the charge stored in the capacitance of a dynamic RAM.
2) It can momentarily turn "on" a transistor that should be off (even turning it more "on" than it normally would be, so its conduction swamps that of its turned-on partner in a totem-pole stage.)
Leaking the stored charge in a RAM flips the bit - in a particular direction. Turning on a transistor that should be off may flip a bit in a flop. latch, or static RAM, or momentarily cause the wrong level on a logic line.
Nothing to do with changed capacitance (although the sudden appearance of an extra conductive region does represent an increased capacatance on some nearby conductors).
Cosmic rays (fast charged nuclear fragments) can do this. Another problem was alpha particles from heavy elements in the ceramic integrated circuit packages once used for memory and mil-spec ICs (which is why they disappeared). A third was alpha particles from the decay of radon gas. (Turns out some locations in Silicon Valley have a lot of radon.)
I believe the grandparent meant "would it be so difficult for MicroSoft to set the file attribute on the hosts file to read only".
Yep. They're two sides to the same issue, really:
With respect to each and every one of the huge number of configuration security bugs that Microsoft ships as its default configuration: Is it the job of millions of customers, many non-experts, to separately change their configuration to turn off the bugs (that they CAN turn off)? Or is it the job of the experts at Microsoft to do this once for everybody?
If it's the latter, aren't they failing in their minimal responsibilities with respect to producing a consumer product? If they are failing, when will the bulk of the consumers realize it and switch to a product that is more robust?
IMHO this is finally starting to happen. And once we're past the tipping point MicroSoft will be in the position of trying to sweep back the avalanche.
Hell, I learned assembly by writing a disassembler (in BASIC) and reading the Microsoft BASIC roms, then later reading the commented listings that ran in Color Computer Magazine. (TO avoid a copyright fight, and because M$ refused to grant them permission, CCM ran only the comments and memory locations, leaving the reader to run their own dissassembly for the opcodes.)
Regardless of the ethics, reading other people's code is, IMHO, the single best way to learn how coding works. And decompiling from object gives you a DAMNED throough understanding of the guts.
I too cut my programming teeth reverse engineering other people's code. And desipte having had an excelent formal programming education from some of the best in the field (Galler, Riddle, Blue,...) I still put the formal instruction third in the list of activities that taught me how to code well, with reverse-engineering from object (sometimes accompanied by very distantly related source code) first and "playing" (writing and using my own software and experimenting with the machines' behavior) second. (Fourth, and still important, was trade journals and other publications.)
I find it amazing that a state like Mississippi which voted to ban gay marriage by huge majority still had a comparably close race for president. So it must be something else.
It's not inconsistent at all.
There are a number of issues that might be important to a voter. Potential voters are not a unified mass with identical opinions, or a collection of a small number of such masses of clones. Instead, each individual has a distinct opinion, and a distinct importance weighting, on each issue.
Once people have come out to vote, they will vote their opinion, not just on the issue that decided their presidential choice, but on every issue on which they have a preference, regardless of how strong the preference or how much importance they hang on the issue.
For a (possibly small) fraction of the voters the gay marriage thing is a very important issue. For some it would make the election important enough to go vote even if they otherwise would have skipped it. For others (probably far more) it would swing their vote to a candidate they would have opposed if the issue had not been in play and they'd decided on the next most important issue.
But there are a lot of people for whom their presidential choice was made on other issues - War, Economy, Taxes, Health Care, Education, Anti-terrorism, anti-anti-terrorism-side-effects, etc. - who also have an opinion on gay marriage. A lot of such people might have voted for Kerry for president but against gay marriage.
There aren't two sides to an issue. At the US federal level there are hundreds of millions to each of many issues. There may be a LOT of clustering. But to assume the voters are identical clones of a handfull of stereotypes is to make the same mistake as the Media make when they say, for instance, that ALL Boomers are drug-swilling hedonists and ALL gen-Xers are Punks in business suits, that ALL blacks are gangsters, and so on.
Now, my response to this is: newWithValue is *nothing special*. It has no special semantics that make it different from other messages. As such, the message setField: called inside newWithValue: is no different than an external entity calling setField: directly. And in the latter case, you expect the subclass implementation to be called, and as such, you should expect the same from the "constructor".
So, what I'm wondering is, what's "wrong" about this? To me, it seems like the height of consistency, especially when you understand that newWithValue: is just like any other message. As such, it's simply up to the programmer to avoid doing something stupid.
Yep, it's "wrong". Here's the reason:
The init functions are executed from base (super) toward derived (sub) classes. If the derived class version of the funciton requires the init at its level to have been run in order to perform correctly, being called due to the execution of a baseward init before the derived class init runs breaks the code.
An example of ways this happens is when one of the lower levels of your class hierarchy links the instance you're constructing/initting into a list of all instances of this class tree, the overridden function is one that is used by external clients which run the list (to obtain the correct flavor of activity for each subclass instance), and such running of the list and calling of the function may be provoked by a side-effect of the construction/initialization or by an external asynchronous event (such as the arrival of a message or a screen refresh). The baseward function might be a no-op while the derived class version performs a job that requires initialization to be complete - at least to its level.
At the time we first encountered this issue, it broke us for two things we wanted to to.
One was garbage collection: The overridden function gave a list of the pointers at this and lower levels for the garbage collector to follow. If something called during construction did memory allocation it might provoke the garbage collector to start. If the devived class version of the function was called, the garbage collector would follow uninitialized pointers. Of course any disturbance (such as adding instrumentation to try to find out what was going wrong) would result in different memory allocation causing the garbage collection to happen at a different stage of execution. Thus a heisenbug.
The other was exception handling: At the time "catch" and "throw" were reserved words in the language specification, so we wrote out own routines. A large fraction of exceptions would be the result of problems during construction that would requrie the abortion of the construction and the destruction of the object to free resources siezed at lower levels. The destructor was also virtual, so calling it would get the correct destruction routines called ONLY IF you got exactly the deepest level where construction had already occurred. Because of the ambiguity in C++ we couldn't throw such exceptions from member objects because (depending on the compiler) they might run the current-level destructor when the corresponding constructor had not run, so the destructor would be operating from uninitialized variables. Trying to hack up the equivalent in Objective C or Smalltalk would result in ALL the levels of the destructor-equivalent being run, regardless of the level of construction/init achieved before the exception. (Of course Smalltalk dosen't itself have the concept of termination, since the deallocation mechanism is to "lose" the object, but that's a separate issue.)
Our workaround at the time was to completely eschew member objects with non-trivial behavior on construction/destruction. Instead we used only pointers to them, allocating them on the heap in the constructor after the member variables that would point to them were initialized to null. This resulted in enormous extra memory management overhead and turned the data structure into a Smalltalk-style mass of l
Im not sure if its a good thing or a bad thing that Microsoft is starting to officially recognize and acknowledge its competition.
- They want people with Microsoft platforms to run the test.
- Some of them have abandoned IE for other browsers (such as Firefox).
- So to get non-IE browser users to run the test they have to tell them it will work on other browsers, and give special instructions for the users of browsers (Firefox) who might have to do something different to get it to run.
In this case it's more valuable to them to actually mention the other brwosers than to keep it mum, because getting more people to run the tool is less important to them than avoiding letting people know that there are options available.
Firefox penetration is quite large - especially among both people likely to have a pirated copy. And I'd IE replacement in general is getting up there at government and corporate sites, now that the US government's antiterrorist operation has issued specific warnings against IE as a hole for terrorist attacks on the US information infrastructure.
No matter how low your opinion of Portland ...
on
C++ In The Linux kernel
·
· Score: 0, Offtopic
Linus is rolling in his grave.
No matter how low your opinion of Portland, moving there is NOT as bad as dying.
Re:(d) There's a big fat hole in the standard.
on
C++ In The Linux kernel
·
· Score: 2, Interesting
Everywhere else C++ uses extreme care to get the "right" level of virtual function.
(Or overridden functions in general, whether virtual or not.)
(d) There's a big fat hole in the standard.
on
C++ In The Linux kernel
·
· Score: 2, Interesting
My pet peve: the gaping hole in the standard regarding the use of virtual functions from constructors and destructors and routines that serve them.
If a member object's constructor, or a routine it calls, somehow gets hold of a pointer to the containing object and calls a virtual function, IMHO it should be performing a legal operation and should get the BASE CLASS version of the function. Ditto in the destructor. (At this stage of construction the base class is fully functional, while the derived class is not yet initialized making attempts to call its version of the function massively broken.) Ditto during destruction. The derived class version should be the one you get beginning with the first line of the body code of the constructor and ending with the last line of the body code of the destructor. (The object transitions during those sections of code, which can be coded carefully to only use virtual member functions whose support is initialized.)
Everywhere else C++ uses extreme care to get the "right" level of virtual function. (This is unlike Objective C and Smalltalk, which "get it wrong" big time by calling derived class (subclass) versions in base class (superclass) construction code, breaking the already-debugged code.) But here the standards - and the implementors - missed an imporatant point.
With an opportunity for both construction and destruction code to get it "right" (call the base class version) or" wrong" separately you have four binary combinations - of which one is "right" and three "wrong". In the early days (pre-standard), cfront got it "wrong" one way, gcc another way, and three commercial compilers for PCs the third way. (So the standard would have imposed equal pain by prescribing the "right" way, leaving them all "broken".) But the first ANSII standard explicitly left it undefined, while the second one not only affirmed that but explicitly warned against calling virtual functions from constructors and destructors.
(I did bring this up with the committee both times, but was unable to sway them, even to make it a recommendation or to provide a "pedantic construction/destruction order" switch.)
Getting it "right" would have had considerable benefits. There's a lot of useful things (which I won't go into here) that become easy if it's "right" and breaks badly - or requires combersome workarounds - if it's "wrong". And getting it "wrong" also leads to subtle bugs and interactions even if you're NOT trying to do something fancy.
(Because it was "wrong" in all the compilers and not forced by the standard, a large programming project I was working on back then was forced into workarounds that gutted the opportunities to build complex objects using member objects, replacing them with smalltalk-style heap-allocated objects strung together by pointers (with enormous overhead as a reault) and creating an initialization function hierarchy parallel to the construction hierarchy to get things properly spun up.
In the kernel the code must be solid and really should be tight and do things the obvious and simple way. So a feature-gutting, bug-attracting, spec ambiguity like this is a nightmare.
I've done software for engine control computers. And I've seen the reliability necessary in automotive softwrae, and the reasons for it. (One example I was involved in fixing: If the idle speed control algorithm tends to stall the engine about a car length after starting up at a stop sign you've got serious problems.)
I will NEVER buy a car with Microsoft software applications built-in at ANY level. (Even if it is (allegedly) only an audio system. A BSOD on the sound system will distract the driver who will try to fix it - and a 95 Db screech will make him lose control.)
EVERY system in a car may become life-critcial under certain circumstances. Microsoft has a track record of dangerous software bugs. If an auto manufacturer uses their products ANYWHERE IN THE CAR it tells me their engineering standards have slipped unacceptably from those considered minimal in the '60s and '70s (and they're considerably higher now.)
[...] the system that was hacked was a Windows 2000 Pro box running SQL Server [...]
When the OS, app, and "known vulnerability" weren't named in the articles, I figured that it must be Microsoft. If it had been Linux or BSD the newsies would have trumpeted it. Instead they protected Microsoft by leaving the reader to guess - and to guess, since it was Berkeley, it was probably BSD (even though it was in a social rather than computer department).
(It reminds me of the way the newsies treat others on their good and bad lists, but I won't name names and start a flame war. B-) )
I'd just suggested using "push mouse button" chords on the chord keyboard (which I visulalize as a ball with buttons you're holding in one hand).
But eyelid gestures make good sense, even if you WERE joking. B-) Also eyebrow gestures, though that would take an extra scanner (or a bit of mirror to let the same scanner "paint" your eyebrows with infrared).
It would be GREAT for quadraplegics.
Of course a person using it would look REALLY silly, though a careful choice of gestures might mitigate that.
The Scouring of the Shire IS the climax of the books. It shows that they have, in effect, grown up and are able to stand on their own two feet and take care of themselves.
Hear hear!
My gripe is that one of the points of Tolkien's book is that evil was pervasive and had to be rooted out everywhere. The perversion of the Shire was what brought it all home, and the Scouring is where it was set right through great effort.
Without the Scouring, the movie makes it look like the hobbits came back from their tremendous struggle to a shire that had sat out the whole war without a blade of grass touched.
The Switzerland of Middle Earth? Even Switzerland didn't fare that well in WW II. (And they got off as lightly as they did because every last one of them was trained, armed, and prepared to ambush and repell anybody who tried to come through THEIR mountains - quite unlike the carefree fuzzy-footed little villagers portrayed in both the book and the movie.) "Switzerland doesn't HAVE an army - it IS an army."
By omitting the Scouring but showing the companions drinking together at a pub in an apparently undamaged and uncaring homeland, the movie commits extreme revisionism on the original work.
Which is not to say it's trash. It's AMAZING that so much of Tolkein's work made it so well to the silver screen. But even if it made the movie "impossible" for the theaters I really think at least some tiny bit of The Scouring should have been filmed and included in the extended edition. (Isn't that what extended editions are for?)
Other advantages: Security, pointing device.
on
Wearable LCD Display
·
· Score: 3, Interesting
Another advantage of an RSD is that it is a spinoff of a device to scan the retina, and adding one more beam-splitter and a photodiode on the laser side of the scanner lets the display do this, too.
That leads to two extra functions:
1) The retina print can be used for a "password". (Fewer worries about somebody who steals your wearable getting at your data or using your comm account to make 20-hour calls to 900 services in Malagua or spam the whole internet.)
2) The display can measure where you're looking - and use that (with suitable algorithms to keep the cursor from being obtrusive) as your pointing device. (Look-and-click means one less device in your hand, i.e. a chord keyboard with mouse button chords in its vocabulary. And it ought to be a bunch faster than mousing.)
This means you can "draw" your character once in a 3D program and then produce a million drawings by simply posing its skeleton in different positions or moving the camera to arbitrary angles. Especially interesting is the ability to produce unlimited in-between frames with simple 3D interpolation of object positions instead of expensive, laborious hand drawing.
Unfortunately, simply "betweening" produces rotten motion. Robotic: constant speed from one position to another, then a discontinuous change to constant speed on the way to the third position, and so on. (For a hand drawn example look at the animation sequences in Pink Floyd's "The Wall".) Splines and accelleration rules help but don't get it right. (Good for animations of robotic characters, though. B-) )
Physical modeling of mass and muscle is producing some good results. But this gets 'way compliated. (And you also have to model some of the immediate surroundings or the character tends to penetrate them.)
Another good hack is putting actors in black suits with white dots and photographing them from multiple angles as they go through the motions, then solving for their location in three-space.
Lets freeze the carbon dioxide blanketing the earth, and store it underground!... Is this the best we can come up with?
Nope.
Seed the South Pacific with miniscule amounts of iron. This will produce an algae bloom which will suck out a LOT of CO2 and sequester much of it in the lower ocean for millenia. A C47 or two with sprayers could handle the job easily.
Downside: Overdo it and you might start a new ice age - with a positive feedback loop to KEEP it cold. (Low CO2 -> lower temperatures -> less evaporation and more water accumulation in polar ice caps -> bigger deserts -> more dust in air -> some dust is nutritious and feeds South Pacific algae.)
The only concern I have is the idea of putting the liquid CO2 in the ground. What impact will that have on other systems of our planet?
If it stays put, nothing. Eventually (over geologic time) it will probably "cook", along with underground minerals and traces of water, into carbonates, methane, or even oil (depending on what's around it). (Not that it will matter to us. By the time that happens it's unlikely (absent major STABILIZING technology applied to the human genome) that any lifeforms on the planet will be recognizable as human by current standards.
Will probably cause earthquakes, though, as such injection of other liquids has done in the past. (Imagine a hydraulic jack the size of a middle-tier state, applied to a faultline.)
If it leaks, bad news. It will form a CO2 bubble on the ground and kill everything for miles around. (This has happened with CO2 injection wells in the past used for squeezing more oil out of the rocks. This proposal would mean a LOT more injection, and probably more such accidents.)
How is this diffrent then toxic waste from nuclear plants being stored under ground....
Much more hazardous, especially on an immediate basis.
Liquid CO2, pushed down injection wells under pressure, occasionally springs a leak. When this happens you suddenly get a giant bubble of CO2 on (and in) the ground, displacing the oxygen and killing everybody and everything (even plants if it persists in the soil long enough) for miles around.
This has happened when CO2 injection was used to pressurize oil wells to squeeze more oil out of the gound.
A similar phenomenon happens naturally (though fortunately VERY rarely) when largely CO2 volcanic gasses vent into a deep still lake (such as in a volcanic crater). The gasses disolve, carbonating the lower waters. Then suddenly something disturbs the water and some of the carbonated water comes up and starts to bubble - rapidly "turning over" and boiling out the CO2 in the rest of the lake in a matter of minutes and releasing a similar ground-hugging toxic bubble.
Think of a shaken soda can the size of Lake Tahoe.
if we continue storring all this wouldn't eventually run out of place to put it?
Nuclear, at least, takes up very little space and decays over years/centuries/millenia (depending on the isotope - generally the hotter the faster). Some of its components are also useful and can be separated out and put to work. Others can be "burned" in nuclear reactions into less hazardous and/or more useful material.
That's not to say it's safe or good stuff. Some of it is horrid. But "running out of room" isn't the problem. (Keeping it in its room until it promises to be a good little kid and MEANS it is the problem.)
Slashdot Mirror
I'm not sure that I've ever seen the terms "orbital" and "price-competitive" in the same paragraph before.
It costs BILLIONS to build a large electrical plant and its related infrastructure. That makes some rather expensive efforts competitive.
Consider a steam plant in orbit. Fuel is free: Sunlight at over 6 times the intensity at the earth's surface, 24/7. Collectors and radiators are feather-light because they don't have to fight gravity or be protected from oxidation, dirt, and mositure. Ditto for the downlink antennas. The actual generation mechanism is pretty small and so can be reasonably light. Downlink transmitters are moderately big - but they're just integrated circuits and/or IC/vacuum tube hybrids (with lots of high-quality vacuum available). Ground structure is a few acres of desert or pasture with a rather open antenna structure over it, and a small building for the DC/AC conversion and pilot transmitter. (You can graze cattle under it if it's pasture, desert life won't be bothered once construction is done - and it will find more shelter among the structures.)
Build the station in low orbit and it can power its own ion engines to move itself up to its final synchronous-orbit site.
Compare that to moving mountains to build a plant on the ground and more to dig up fuel and transport it, building stacks and pollution filters, disposing of scrubbed ash and acids, buying land for the site and the railroad or pipeline to feed it, making everything strong enough to resist gravity, protesters, and sabateurs.
You can afford a LOT of launches, even of the shuttle, with a budget like that.
Far from the impact crater a *lot* of vegetation survived - this is what destroyed earlier theories about a worldwide fire (it was actually quite localized).
Are we back to nuclear winter (like) theories? Now I'm really confused.
I was under the impression that the nuclear winter theories were the old ones, and that they were very recently supplanted by the global fire scenario. This happened when some physicists started wondering what would happen to all the debris kicked up by the impact, did some calculations, and came to the conslusion that they would go out of the atmosphere and then rain down all over the planet - turning the sky into the equivalant of the inside of a broiler oven for several hours, dessicating plants and starting the fires worldwide. Global forest/grass fires would then kill off everyting that wasn't in an underground shelter or underwater when the sky lit up. (Afterward there'd be lots of starvation, pollution, and the like. But first there was the accute broiling of everything above ground.)
This was then compared to the surviving critter mix, and it was observed that on one side of the planet the survivors were largely nocturnal burrowers and on the other side they were diurnal, leading to an estimate of the time of day of the impact. Also: Lots of fire ash was found, worldwide, at the C-T boundary along with the irridium.
A fire scenario would account for the survival of the bees. Hives in rock-sheltered locations wouldn't be subject to burnout. The reproductive members of the hive would be IN the hive, and would stay in through the fire. Within a year or less, flowering weeds would regrow from taproots and begin feeding the hive (which can survive for a LONG time - several years - on its stored honey and pollen.)
Are you saying that this relatively recent scenario was debunked, and they're back to "nuclear winter"?
No, the dance theory has to do with how a forager bee tells the rest of the workers precicely where the food is that he found. The legend goes that he first spins one way X times to denote the direction, then the other way X times to denote the distance.
The descriptions of the "waggle dance" I've seen don't match the one you give. They're more like this:
The dancing forager bee does a figure-8 path around a slashed-circle - like the capital leter theta. The straight run is what's significant.
The angle of the striaght run with the vertical is the same as the angle between the sun and the path to the food. The bee waggles its butt while on the straight path, and the number of waggles is proportional to the flight effort to get to the food under prevailing wind conditions.
The surrounding bees observe the dance, pick up the scent of the food source off the dancing bee, then take off BEFORE it goes out for another load.
I hear Intel is integrating WiMAX into a chip to go on the laptop motherboard - and that this chip/core/whatever is also capable of WiFi.
WiFi(b, g) could be viewed as a slightly degraded version of the OFDM/OFDMA PHYs of WiMAX, operating just adjacent to one of WiMAX's several bands, with a somewhat different MAC. So it's easy to do with the same hardware. The DSP has more than enough capacity and runs much the same algorithms, the radio can tune the band, and the MAC logic is related but simpler, and well-debugged. 802.11a isn't that much different either, and also in range of the radio. So once you have working designs for each it's pretty trivial to do both WiMAX and WiFI in the same chip (at least if you're not trying to do them at the same time).
Perhaps this release thrash is related to that.
What I want to know is when WiMAX becomes a standard part of the laptop support chip line.
Unfortunately, the radical greens have shot down the only really viable means for radically reducing CO2 output, nuclear power.
Actually there are (at least) two others. But I'm sure the eco-fascists (not to be confused with actual environmental scientists) would be opposed to them as well.
One is space solar power: Orbital solar collectors and milimeter-wave downlink to rectennas. It's actually price-competitive with fossil fuel plants (despite a flawed NASA study) and will get moreso with the development of private orbital capacity. (Bullshit about birds cooked in flight has already been issued.)
The other is to seed the South Pacific with a bit of iron compounds so the algae bloom will suck down megatons of CO2 and sequester it in the deep ocean for time measured in kiloyears, and continue with fossil fuel until, say, the necessary fusion breakthroughs occur or the eventual price rises make other alternatives attractive.
It seems odd to see them whine on one hand about too much CO2, and then whine on the other hand that people would *gasp* actually consider using a CO2 free source of electricity.
Hear hear!
These heavily charged extremely small particles have the property that they change the capacitance of parts of semiconductors when passed through them.
Close but no cigar.
The rapid passage of a charged particle deposits enough energy on nearby charged particles to jog them out of place - creating a sudden conductive sea of electron-hole pairs. These charge carriers are then swept away by the local field, becoming a burst of current.
This affects memory and logic devices in two ways:
1) It can suddenly leak away the charge stored in the capacitance of a dynamic RAM.
2) It can momentarily turn "on" a transistor that should be off (even turning it more "on" than it normally would be, so its conduction swamps that of its turned-on partner in a totem-pole stage.)
Leaking the stored charge in a RAM flips the bit - in a particular direction. Turning on a transistor that should be off may flip a bit in a flop. latch, or static RAM, or momentarily cause the wrong level on a logic line.
Nothing to do with changed capacitance (although the sudden appearance of an extra conductive region does represent an increased capacatance on some nearby conductors).
Cosmic rays (fast charged nuclear fragments) can do this. Another problem was alpha particles from heavy elements in the ceramic integrated circuit packages once used for memory and mil-spec ICs (which is why they disappeared). A third was alpha particles from the decay of radon gas. (Turns out some locations in Silicon Valley have a lot of radon.)
I believe the grandparent meant "would it be so difficult for MicroSoft to set the file attribute on the hosts file to read only".
Yep. They're two sides to the same issue, really:
With respect to each and every one of the huge number of configuration security bugs that Microsoft ships as its default configuration: Is it the job of millions of customers, many non-experts, to separately change their configuration to turn off the bugs (that they CAN turn off)? Or is it the job of the experts at Microsoft to do this once for everybody?
If it's the latter, aren't they failing in their minimal responsibilities with respect to producing a consumer product? If they are failing, when will the bulk of the consumers realize it and switch to a product that is more robust?
IMHO this is finally starting to happen. And once we're past the tipping point MicroSoft will be in the position of trying to sweep back the avalanche.
But perhaps that is wishful thinking.
Hell, I learned assembly by writing a disassembler (in BASIC) and reading the Microsoft BASIC roms, then later reading the commented listings that ran in Color Computer Magazine. (TO avoid a copyright fight, and because M$ refused to grant them permission, CCM ran only the comments and memory locations, leaving the reader to run their own dissassembly for the opcodes.)
...) I still put the formal instruction third in the list of activities that taught me how to code well, with reverse-engineering from object (sometimes accompanied by very distantly related source code) first and "playing" (writing and using my own software and experimenting with the machines' behavior) second. (Fourth, and still important, was trade journals and other publications.)
Regardless of the ethics, reading other people's code is, IMHO, the single best way to learn how coding works. And decompiling from object gives you a DAMNED throough understanding of the guts.
I too cut my programming teeth reverse engineering other people's code. And desipte having had an excelent formal programming education from some of the best in the field (Galler, Riddle, Blue,
I find it amazing that a state like Mississippi which voted to ban gay marriage by huge majority still had a comparably close race for president. So it must be something else.
It's not inconsistent at all.
There are a number of issues that might be important to a voter. Potential voters are not a unified mass with identical opinions, or a collection of a small number of such masses of clones. Instead, each individual has a distinct opinion, and a distinct importance weighting, on each issue.
Once people have come out to vote, they will vote their opinion, not just on the issue that decided their presidential choice, but on every issue on which they have a preference, regardless of how strong the preference or how much importance they hang on the issue.
For a (possibly small) fraction of the voters the gay marriage thing is a very important issue. For some it would make the election important enough to go vote even if they otherwise would have skipped it. For others (probably far more) it would swing their vote to a candidate they would have opposed if the issue had not been in play and they'd decided on the next most important issue.
But there are a lot of people for whom their presidential choice was made on other issues - War, Economy, Taxes, Health Care, Education, Anti-terrorism, anti-anti-terrorism-side-effects, etc. - who also have an opinion on gay marriage. A lot of such people might have voted for Kerry for president but against gay marriage.
There aren't two sides to an issue. At the US federal level there are hundreds of millions to each of many issues. There may be a LOT of clustering. But to assume the voters are identical clones of a handfull of stereotypes is to make the same mistake as the Media make when they say, for instance, that ALL Boomers are drug-swilling hedonists and ALL gen-Xers are Punks in business suits, that ALL blacks are gangsters, and so on.
would it be so difficult ... to set the file attribute on the hosts file to read only.
a) Why should Joe Newbie Windowsbuyer be expected to KNOW that he needs to change the permissions on the host file from the install defaults?
b) If he can do it, he can UNdo it, and so can the bad guy's script.
c) How many OTHER holes would he have to fix? Thousands? Tens of thousands? (Remember, he only has to miss ONE.)
Now, my response to this is: newWithValue is *nothing special*. It has no special semantics that make it different from other messages. As such, the message setField: called inside newWithValue: is no different than an external entity calling setField: directly. And in the latter case, you expect the subclass implementation to be called, and as such, you should expect the same from the "constructor".
So, what I'm wondering is, what's "wrong" about this? To me, it seems like the height of consistency, especially when you understand that newWithValue: is just like any other message. As such, it's simply up to the programmer to avoid doing something stupid.
Yep, it's "wrong". Here's the reason:
The init functions are executed from base (super) toward derived (sub) classes. If the derived class version of the funciton requires the init at its level to have been run in order to perform correctly, being called due to the execution of a baseward init before the derived class init runs breaks the code.
An example of ways this happens is when one of the lower levels of your class hierarchy links the instance you're constructing/initting into a list of all instances of this class tree, the overridden function is one that is used by external clients which run the list (to obtain the correct flavor of activity for each subclass instance), and such running of the list and calling of the function may be provoked by a side-effect of the construction/initialization or by an external asynchronous event (such as the arrival of a message or a screen refresh). The baseward function might be a no-op while the derived class version performs a job that requires initialization to be complete - at least to its level.
At the time we first encountered this issue, it broke us for two things we wanted to to.
One was garbage collection: The overridden function gave a list of the pointers at this and lower levels for the garbage collector to follow. If something called during construction did memory allocation it might provoke the garbage collector to start. If the devived class version of the function was called, the garbage collector would follow uninitialized pointers. Of course any disturbance (such as adding instrumentation to try to find out what was going wrong) would result in different memory allocation causing the garbage collection to happen at a different stage of execution. Thus a heisenbug.
The other was exception handling: At the time "catch" and "throw" were reserved words in the language specification, so we wrote out own routines. A large fraction of exceptions would be the result of problems during construction that would requrie the abortion of the construction and the destruction of the object to free resources siezed at lower levels. The destructor was also virtual, so calling it would get the correct destruction routines called ONLY IF you got exactly the deepest level where construction had already occurred. Because of the ambiguity in C++ we couldn't throw such exceptions from member objects because (depending on the compiler) they might run the current-level destructor when the corresponding constructor had not run, so the destructor would be operating from uninitialized variables. Trying to hack up the equivalent in Objective C or Smalltalk would result in ALL the levels of the destructor-equivalent being run, regardless of the level of construction/init achieved before the exception. (Of course Smalltalk dosen't itself have the concept of termination, since the deallocation mechanism is to "lose" the object, but that's a separate issue.)
Our workaround at the time was to completely eschew member objects with non-trivial behavior on construction/destruction. Instead we used only pointers to them, allocating them on the heap in the constructor after the member variables that would point to them were initialized to null. This resulted in enormous extra memory management overhead and turned the data structure into a Smalltalk-style mass of l
Im not sure if its a good thing or a bad thing that Microsoft is starting to officially recognize and acknowledge its competition.
- They want people with Microsoft platforms to run the test.
- Some of them have abandoned IE for other browsers (such as Firefox).
- So to get non-IE browser users to run the test they have to tell them it will work on other browsers, and give special instructions for the users of browsers (Firefox) who might have to do something different to get it to run.
In this case it's more valuable to them to actually mention the other brwosers than to keep it mum, because getting more people to run the tool is less important to them than avoiding letting people know that there are options available.
Firefox penetration is quite large - especially among both people likely to have a pirated copy. And I'd IE replacement in general is getting up there at government and corporate sites, now that the US government's antiterrorist operation has issued specific warnings against IE as a hole for terrorist attacks on the US information infrastructure.
Linus is rolling in his grave.
No matter how low your opinion of Portland, moving there is NOT as bad as dying.
Everywhere else C++ uses extreme care to get the "right" level of virtual function.
(Or overridden functions in general, whether virtual or not.)
My pet peve: the gaping hole in the standard regarding the use of virtual functions from constructors and destructors and routines that serve them.
If a member object's constructor, or a routine it calls, somehow gets hold of a pointer to the containing object and calls a virtual function, IMHO it should be performing a legal operation and should get the BASE CLASS version of the function. Ditto in the destructor. (At this stage of construction the base class is fully functional, while the derived class is not yet initialized making attempts to call its version of the function massively broken.) Ditto during destruction. The derived class version should be the one you get beginning with the first line of the body code of the constructor and ending with the last line of the body code of the destructor. (The object transitions during those sections of code, which can be coded carefully to only use virtual member functions whose support is initialized.)
Everywhere else C++ uses extreme care to get the "right" level of virtual function. (This is unlike Objective C and Smalltalk, which "get it wrong" big time by calling derived class (subclass) versions in base class (superclass) construction code, breaking the already-debugged code.) But here the standards - and the implementors - missed an imporatant point.
With an opportunity for both construction and destruction code to get it "right" (call the base class version) or" wrong" separately you have four binary combinations - of which one is "right" and three "wrong". In the early days (pre-standard), cfront got it "wrong" one way, gcc another way, and three commercial compilers for PCs the third way. (So the standard would have imposed equal pain by prescribing the "right" way, leaving them all "broken".) But the first ANSII standard explicitly left it undefined, while the second one not only affirmed that but explicitly warned against calling virtual functions from constructors and destructors.
(I did bring this up with the committee both times, but was unable to sway them, even to make it a recommendation or to provide a "pedantic construction/destruction order" switch.)
Getting it "right" would have had considerable benefits. There's a lot of useful things (which I won't go into here) that become easy if it's "right" and breaks badly - or requires combersome workarounds - if it's "wrong". And getting it "wrong" also leads to subtle bugs and interactions even if you're NOT trying to do something fancy.
(Because it was "wrong" in all the compilers and not forced by the standard, a large programming project I was working on back then was forced into workarounds that gutted the opportunities to build complex objects using member objects, replacing them with smalltalk-style heap-allocated objects strung together by pointers (with enormous overhead as a reault) and creating an initialization function hierarchy parallel to the construction hierarchy to get things properly spun up.
In the kernel the code must be solid and really should be tight and do things the obvious and simple way. So a feature-gutting, bug-attracting, spec ambiguity like this is a nightmare.
Thus for me:
* (d) There's a big fat hole in the standard.
Is a killer.
I've done software for engine control computers. And I've seen the reliability necessary in automotive softwrae, and the reasons for it. (One example I was involved in fixing: If the idle speed control algorithm tends to stall the engine about a car length after starting up at a stop sign you've got serious problems.)
I will NEVER buy a car with Microsoft software applications built-in at ANY level. (Even if it is (allegedly) only an audio system. A BSOD on the sound system will distract the driver who will try to fix it - and a 95 Db screech will make him lose control.)
EVERY system in a car may become life-critcial under certain circumstances. Microsoft has a track record of dangerous software bugs. If an auto manufacturer uses their products ANYWHERE IN THE CAR it tells me their engineering standards have slipped unacceptably from those considered minimal in the '60s and '70s (and they're considerably higher now.)
[...] the system that was hacked was a Windows 2000 Pro box running SQL Server [...]
When the OS, app, and "known vulnerability" weren't named in the articles, I figured that it must be Microsoft. If it had been Linux or BSD the newsies would have trumpeted it. Instead they protected Microsoft by leaving the reader to guess - and to guess, since it was Berkeley, it was probably BSD (even though it was in a social rather than computer department).
(It reminds me of the way the newsies treat others on their good and bad lists, but I won't name names and start a flame war. B-) )
But how do you select text, Wink and roll?
I'd just suggested using "push mouse button" chords on the chord keyboard (which I visulalize as a ball with buttons you're holding in one hand).
But eyelid gestures make good sense, even if you WERE joking. B-) Also eyebrow gestures, though that would take an extra scanner (or a bit of mirror to let the same scanner "paint" your eyebrows with infrared).
It would be GREAT for quadraplegics.
Of course a person using it would look REALLY silly, though a careful choice of gestures might mitigate that.
The Scouring of the Shire IS the climax of the books. It shows that they have, in effect, grown up and are able to stand on their own two feet and take care of themselves.
Hear hear!
My gripe is that one of the points of Tolkien's book is that evil was pervasive and had to be rooted out everywhere. The perversion of the Shire was what brought it all home, and the Scouring is where it was set right through great effort.
Without the Scouring, the movie makes it look like the hobbits came back from their tremendous struggle to a shire that had sat out the whole war without a blade of grass touched.
The Switzerland of Middle Earth? Even Switzerland didn't fare that well in WW II. (And they got off as lightly as they did because every last one of them was trained, armed, and prepared to ambush and repell anybody who tried to come through THEIR mountains - quite unlike the carefree fuzzy-footed little villagers portrayed in both the book and the movie.) "Switzerland doesn't HAVE an army - it IS an army."
By omitting the Scouring but showing the companions drinking together at a pub in an apparently undamaged and uncaring homeland, the movie commits extreme revisionism on the original work.
Which is not to say it's trash. It's AMAZING that so much of Tolkein's work made it so well to the silver screen. But even if it made the movie "impossible" for the theaters I really think at least some tiny bit of The Scouring should have been filmed and included in the extended edition. (Isn't that what extended editions are for?)
Another advantage of an RSD is that it is a spinoff of a device to scan the retina, and adding one more beam-splitter and a photodiode on the laser side of the scanner lets the display do this, too.
That leads to two extra functions:
1) The retina print can be used for a "password". (Fewer worries about somebody who steals your wearable getting at your data or using your comm account to make 20-hour calls to 900 services in Malagua or spam the whole internet.)
2) The display can measure where you're looking - and use that (with suitable algorithms to keep the cursor from being obtrusive) as your pointing device. (Look-and-click means one less device in your hand, i.e. a chord keyboard with mouse button chords in its vocabulary. And it ought to be a bunch faster than mousing.)
This means you can "draw" your character once in a 3D program and then produce a million drawings by simply posing its skeleton in different positions or moving the camera to arbitrary angles. Especially interesting is the ability to produce unlimited in-between frames with simple 3D interpolation of object positions instead of expensive, laborious hand drawing.
Unfortunately, simply "betweening" produces rotten motion. Robotic: constant speed from one position to another, then a discontinuous change to constant speed on the way to the third position, and so on. (For a hand drawn example look at the animation sequences in Pink Floyd's "The Wall".) Splines and accelleration rules help but don't get it right. (Good for animations of robotic characters, though. B-) )
Physical modeling of mass and muscle is producing some good results. But this gets 'way compliated. (And you also have to model some of the immediate surroundings or the character tends to penetrate them.)
Another good hack is putting actors in black suits with white dots and photographing them from multiple angles as they go through the motions, then solving for their location in three-space.
Or you can do it by hand and deveop THAT art.
This has happened when CO2 injection was used to pressurize oil wells to squeeze more oil out of the gound.
They are still doing this. Any pointers to the deaths you mentioned?
Sorry. Saw it in a newspaper decades ago.
Lets freeze the carbon dioxide blanketing the earth, and store it underground! ... Is this the best we can come up with?
Nope.
Seed the South Pacific with miniscule amounts of iron. This will produce an algae bloom which will suck out a LOT of CO2 and sequester much of it in the lower ocean for millenia. A C47 or two with sprayers could handle the job easily.
Downside: Overdo it and you might start a new ice age - with a positive feedback loop to KEEP it cold. (Low CO2 -> lower temperatures -> less evaporation and more water accumulation in polar ice caps -> bigger deserts -> more dust in air -> some dust is nutritious and feeds South Pacific algae.)
The only concern I have is the idea of putting the liquid CO2 in the ground. What impact will that have on other systems of our planet?
If it stays put, nothing. Eventually (over geologic time) it will probably "cook", along with underground minerals and traces of water, into carbonates, methane, or even oil (depending on what's around it). (Not that it will matter to us. By the time that happens it's unlikely (absent major STABILIZING technology applied to the human genome) that any lifeforms on the planet will be recognizable as human by current standards.
Will probably cause earthquakes, though, as such injection of other liquids has done in the past. (Imagine a hydraulic jack the size of a middle-tier state, applied to a faultline.)
If it leaks, bad news. It will form a CO2 bubble on the ground and kill everything for miles around. (This has happened with CO2 injection wells in the past used for squeezing more oil out of the rocks. This proposal would mean a LOT more injection, and probably more such accidents.)
How is this diffrent then toxic waste from nuclear plants being stored under ground....
Much more hazardous, especially on an immediate basis.
Liquid CO2, pushed down injection wells under pressure, occasionally springs a leak. When this happens you suddenly get a giant bubble of CO2 on (and in) the ground, displacing the oxygen and killing everybody and everything (even plants if it persists in the soil long enough) for miles around.
This has happened when CO2 injection was used to pressurize oil wells to squeeze more oil out of the gound.
A similar phenomenon happens naturally (though fortunately VERY rarely) when largely CO2 volcanic gasses vent into a deep still lake (such as in a volcanic crater). The gasses disolve, carbonating the lower waters. Then suddenly something disturbs the water and some of the carbonated water comes up and starts to bubble - rapidly "turning over" and boiling out the CO2 in the rest of the lake in a matter of minutes and releasing a similar ground-hugging toxic bubble.
Think of a shaken soda can the size of Lake Tahoe.
if we continue storring all this wouldn't eventually run out of place to put it?
Nuclear, at least, takes up very little space and decays over years/centuries/millenia (depending on the isotope - generally the hotter the faster). Some of its components are also useful and can be separated out and put to work. Others can be "burned" in nuclear reactions into less hazardous and/or more useful material.
That's not to say it's safe or good stuff. Some of it is horrid. But "running out of room" isn't the problem. (Keeping it in its room until it promises to be a good little kid and MEANS it is the problem.)