Well, not until the British had lost most of its armed forces fighting alongside America against the infidels. After all, why waste ammunition on killing people who are quite happy to sacrifice themselves on your behalf?
...Cheney referred to as the President of Vice before, but it makes sense. Oh, and the President was elected. One man, one vote, with Jeb being the man.
Well, of course! It's called the Piece (of the action) Dividend and involves the militaries of the world diverting money from weapons that make for lousy TV when the reporters are too close into weapons that the news teams can only discuss with expensive CGI graphics. (The only nations that have enough dependency on space telecoms for this to matter are the Europeans. It's possible America will invade Europe at some point - I wonder which way Britain would go, if that happened - but they really don't have the means to right now. All other space powers are either too poor or too new to the game to be able to rely on such methods.)
Snapshots exist for Qt 4, so why not do a port for that? The KDE team'll need to do the port sometime anyway and it doesn't matter if Qt 4's API isn't stable yet provided the difference between the API now and when it stabilizes is less than the difference between the Qt they're using now and the final Qt 4, as they'll still save effort in the long-run. It'd also give them a feel for any tuning needed for Qt 4.
Of course, this is pretty obvious stuff - the bleeding-edge branch of any rapid project is almost invariably going to stay as far ahead of the curve as possible, so that the software is moderately stable by the time the code hits beta-testing and beta-testers can concentrate on QC, not feature-fixing.
Alternative native Window Mangers for Windows
on
KDE 3.5 Beta 1 Announced
·
· Score: 3, Interesting
Why not? Someone ported Afterstep to Windows. It was a native port, too, not using Cygwin. It should be possible for someone to examine how the replacement of the Windows GUI was achieved, and the X calls shouldn't pose a problem as KDE uses Qt, and Qt will run under Windows. Anything KDE doesn't do through Qt should be solvable by looking to see how the Afterstep port solved the problem.
What I'd LOVE to see is someone porting the full KDE system to run natively on Windows, then write a layer that'll handle Windows GUI calls and DirectX through KDE. A screenshot of that would freak out so many people...
I'm not sure it would strictly be illegal, as Google has no contract with AOL or even with the users. For example, if you had a web cache sitting between Google and the consumer, the request for a Google advert would still not reach Google, but web caches nonetheless exist (in America and elsewhere). Indeed, it is the lack of transparency in the web cache for banner adverts is the main objection to them. (The second is the lack of transparency for DRMed content.)
Likewise, a script has no control over how the computer (or any other computer) interprets that script. That's the main reason software companies claim exemption over lemon laws, as it is impossible to know in advance how a program will run. In consequence, if Google's HTML gets directed elsewhere, Microsoft/AOL may be able to claim that they're exempt from "restraint of trade" laws as the way the HTML is interpreted is not dictated by Google but by the recipient's OS and browser.
Oh, it should be illegal, but I'm not convinced that the courts would agree. Hell, Microsoft even convinced the courts that Windows 98 was a different OS and not Windows 95 with the browser built into it and a few bugfixes. (Microsoft was prohibited from building the browser into 95, but by calling the combined package Windows 98 the deal was circumvented.) Although Microsoft was eventually defeated over blocking DR-DOS within Windows 3.1, DR-DOS had changed hands twice and the original company had suffered crippling damage. Microsoft could easily have four, five maybe even ten years between being discovered and anything being done - by which time Google would be as dead as a doornail - and the penalties almost couldn't begin to compare with the profits MS would stand to make if that happened.
It wouldn't have to visibly redirect you. In fact, since Google is financed through advertising, redirecting the search isn't the important part. All you have to do is redirect the advertising banner. Since AOL users will likely access through AOL servers, all it would require is for AOL to proxy all HTTP requests, find the ones for the banner ads, then redirect those to an MSN banner advert server. Actually, since Microsoft controls 98% of all desktops, it could be done even easier. Don't do any filtering at all, but simply change IE so that whenever you go from Google to another site, the HTTP header is mangled to look like the browser's previous page was on MSN.
Both of these would be invisible to the user, very difficult for Google to spot, but visible to advertisers and sponsors, which would potentially cripple Google's revenue stream. (This is why advertising is a lousy business model - anything that exists only on a logical level is totally mutable, making it easy for people to steal.)
In the same way that chip manufacturers are moving away from rad-hardened logic circuits to simply using better shielding AROUND the chip, you'd simply rad-harden the elevator. You'd want a laminate that would probably include a layer of lead, another of graphite and another of iron. If you want to be absolutely sure, you'd probably have marble tiles on the inside of the elevator. (Marble is quite a good blocking material, as well as being decorative.)
The lead would deal with gamma and x-ray (your two biggest problems in space), the graphite would stop neutrons (which I don't believe would be that common, unless as secondary radiation when the elevator gets bombarded) and the iron would stop charged particles - especially beta.
You've also got to consider that dosage would be proportional to time. I doubt anyone is thinking of a space elevator that's the same speed as the service elevator in a University. (Rumor has it that the reason professors look so old is that they decided not to walk up the stairs one day...)
If your speeds are comparable to any conventional launch/re-entry, you barely need any shielding at all. IIRC, most video clips I've seen on launches do NOT show astronauts wearing helmets, but just lead-lined balaclavas. The system I'd implement would be orders of magnitude more resistant, which means you could travel orders of magnitude slower and still not suffer significantly from radiation. (Ten times the shielding would mean you'd need to only go at mach 2.6 to get a comparable radiation dose to shuttle crews. Tough, but if the elevator is possible at all, this would seem to be a very doable restriction.)
Provided you maintained the positive pressure in the central column (another poster suggested utilizing the high winds at the top of skyscrapers), then the central column need not be sealed from the rest of the building at all. In fact, you wouldn't want it to be. You could use conventional smoke doors, rather than crash doors, making it much easier for people to enter or leave. Since you're going to have to keep a high pressure during an evacuation when many doors are open, the leakage the rest of the time cannot be significant. The only reason for having doors at all would be to draught-proof the rooms and corridors.
A "sealed" building is a misleading concept anyway, in this case. Smoke rises because it is hot (which is why, if you're trying to get through smoke, it is often easier if you crawl under it). So, if you had air vents at the far end of the room, into the ceiling, that had a negative pressure, you'd pull smoke away. Will this fan the flames? Probably. But smoke is a far bigger killer than flames, so if you halve the deaths from smoke but double them from fire, you're still going to win by an order or two of magnitude. It's not perfect, but I'd call that kind of reduction a good start by any standards.
Since the two biggest factors in building evacuations are smoke-related (lack of visibility and the toxicity of the smoke), these would seem to be the things to taget in any kind of structural design. The third factor is having an escape route that is unblocked, unaffected by fire or smoke, navigable and large enough to handle the density of traffic going through it. By having the escape route as a central spiral arrangement, you've got a pretty solid structure there that would be resistant to damage in a way that a conventional square arrangement is not. By having a positive pressure, you keep the smoke and fire out (the flames will be fanned towards the outside of the building, away from the escape route). In order to have a central column that can support itself AND the rest of the building by means of ribs, you'd need something that was pretty large, which means you'd have a very wide staircase, which is exactly what you want for large-scale evacuations.
(One of the problems with having many small staircases is that a given staircase will choke rapidly, making escape for those in it much harder. Another is that those NOT on that staircase have to waste valuable time hunting for one clear enough to get down. Having fewer, substantially larger, staircases would reduce latency by eliminating seek time and preventing I/O blocking by having much fatter pipes. (In computing, a single gigabit pipe is generally going to do better than having a hundred ten megabit pipes that are channel bonded together. Since flows are flows, it should make little difference if we apply the principles to escape methods. You want to have a system that can handle randomly-occuring bursts at maximum capacity without choking, which means you want the smoothest flows possible, which typically means a very few very fat pipes for the backbone.)
The problem with burn-up comes from the fact that it would be free-falling almost vertically, whereas the Space Shuttle gets to slice through the atmosphere at a much gentler angle. Besides, the Shuttle generates a LOT of heat - the air turns to plasma, at one point in the descent! (Plasma is a perfectly ionised gas - the atomic nuclei have NO electrons whatsoever surrounding them.)
The Shuttle gets the benefit of the ceramic heat-proof tiles, which would be unusable on an elevator cord, as the tiles are way too fragile to survive having a huge elevator clamped onto them. They'd crush. The tiles are also highly toxic, which makes getting out of the elevator somewhat awkward.
The potential difference between the ends of the cord is the biggest technical problem - you're going to get a potential difference great enough to simply destroy most substances at a fraction of the length required. You're going to have to solve that problem before you're going to get very far.
Building from space and dropping the cord would be disasterous - air resistance from a vertical plunge would destroy it. You're better off attaching the cord to a propellent-free vehicle and firing it up, as you'd have fewer heating problems. Air currents might be a problem (such as pushing against the cord, resuling in the vehicle plunging uncontrollably towards the ground).
Do I think it's better than NASA's solution? Oh, by a long way. I don't think it'll work, but it would advance technology considerably even if it fails to achieve its primary goal. NASA's solution won't advance a damn thing, even if it succeeds.
One British inventor devised a gigantic chute that you could telescope into a relatively small volume and attach to the outside of the building. When there is an emergency, you unlatch the chute and one end falls to the ground. You then slide down the chute, the friction keeping you from travelling dangerously fast.
Personally, I'd have thought it simpler to have a central spiral staircase in the building, acting as a sort of spinal cord. You then create a positive pressure in the staircase, such that smoke in the building will always blow AWAY from it, never towards it. (This prevents the chimney effect that causes so many disasters in tall buildings with continuous staircases.)
By locking everything onto that staircase as ribs, you should get a stronger structure than using the current pile-of-boxes approach.
Nobody I know of is claiming a "significant" contribution prior to 1700 - but if the effect of hurricanes is confirmed, it demonstrates that the impact required to alter weather patterns is an order of magnitude smaller than originally anticipated.
The change in sensitivity estimates means that the slash-and-burn agriculture common in early history may have been enough to create a measurable impact.
First, who decides how critical a bug is? And how do they make that decision? The more wiggle-room there is, the easier it is to adjust the number of critical bugs in your favour and likewise in the opposite direction of competitors.
For that matter, who gets to decide what a bug is, rather than a "feature"? The DRM in the current version of the Acrobat format allows you to run embedded Javascript with no access controls. This is arguably an exploit, but Adobe would doubtless classify it as a feature, as it means you cannot circumvent DRM by turning the Javascript off.
Secondly, the numbers are not directly comparable, as Mozilla is standalone whereas IE is built into the OS. (This is important, as integration means that bugs that are strictly in the OS could be exploited through the web browser, without it being a web browser bug.)
Thirdly, there are deals over the reporting of security holes in software, whereby a report can be held back until a patch has been readied. This means that even "unconfirmed" (but reported) bugs by security vendors may be capped by the manufacturer. (Not always, even with those manufacturers who do this, but it does introduce uncertainty.)
Finally, Mozilla is cross-platform but bugs may not always be. Any buggy code that is OS-specific, for example, or any bug which relies on some OS-specific or library-specific bug in order to be exploitable, may only affect certain platforms as a result.
There is a second part to this one! It is also possible to have one bug that appears in multiple forms, but only one form per OS (due to OS-specific characteristics). Does it count as one bug or as many? (Remember, it still only takes one form in a given OS, but because of dependencies, changes in some way between different operating systems.)
Now, you can argue that many of the above are very hypothetical and do not apply in this specific study. Perhaps that is true, but the point is that unless you have rigorous controls on how you produce the statistics, the uncertainties are bound to be comparable to the number of incidents, making the statistics worthless.
And that is my point. If the possible variance in the number of actual bugs (reported or otherwise) gets to be comparable to the number of bugs reported, then the reports mean nothing. The actual number of bugs encountered could range from zero to infinity and the stats would still be "correct".
Ideally, the security companies would produce sufficient additional information to demonstrate the confidence they have in the values produced as opposed to simply citing the numbers but not really backing them up with anything concrete.
Where uncertainty is required by the vendor, then publish a range or some other indicator of how many unpublishable but reported bugs are believed to exist. (Since there is no guarantee that the unpublishable data is circulated with security vendors, an accurate figure may not be producable at all.)
What I'm looking for is an effect caused by greenhouse effect caused by man-made pollution over time where there is a correlation between hemispherical climate change and human migration.
(Yeesh, that's worse than my original post!)
The bulk of greenhouse gasses, in early human civilization, were released in the southern hemisphere. The bulk of the greenhouse gasses released in later civilization were released in the northern hemisphere.
The air from the two hemispheres mixes, but relatively slowly. In consequence, what you should expect from man-made causes is an effect that ONLY occurs within one hemisphere for a prolonged period of time and then gradually extends into the other hemisphere.
Mixing between hemispheres over periods in which air or water circulation was disrupted for whatever reason, provided it was for a long enough period of time, should result in a much greater disparity between the two hemispheres in atmospheric behaviour, assuming that to be a significant influence.
So, we should expect that hurricanes would have become marginally worse in the southern hemisphere relative to the northern hemisphere, from the dawn of civilization up until the start of the mass migration into the northern hemisphere.
By measuring the two hemispheres independently, as they're largely independent systems with a common source of input from the natural world, and then taking the ratio of major storm systems between the two, you should get a figure that is slightly more in favour of the northern hemisphere to the south because there's more landmass and therefore less reflection of solar energy.
Over the early human civilization, this number should start creeping towards 1:1, or even swinging a little in favour of the south having more severe weather.
Once the northern hemisphere was occupied, the ratio should swing the other way, first back to the "normal" ratio and then more and more towards the north as the impact of humans escallated.
Because this comparison is of a ratio, it eliminates variations caused by solar input, volcanos (where the impact is so great that both hemispheres are affected rapidly), global climate changes (ice ages, etc), and so on. The only things to affect the ratio will be things that don't cross oer the equator so much.
If, as I've suggested, the change migrates, then you also eliminate the possibility of something that is static that disrupted climate.
Finally, if such a migration occurs at about the same time as human migration to the north, you'd have fairly strong evidence that humans were involved in the migration of the cause.
If you see any new concrete bridges going up near the Redmond campus, a discontinued blog and a mysterious cavity showing up when using GPR, we will know how seriously Microsoft takes criticism.
With the idea that a company could have "long-term revenues" planned for out-of-copyright material and abandonware. How do you plan for the long-term, when the material has no intrinsic value and all residual value exists only because someone is looking for that material at that time? What happens next week?
It is because of companies trying to squeeze every last drop out of the residual value that copyright has been extended in time and coverage. In consequence, I have a hard time being sympathetic. If you pursue a commercial model that you know, by definition, is beither tennable nor stable, then why should the rest of society foot the bill?
Did bookshops bail out the dot-com failures? No? Then why should computer companies bail out bookshops who are self-created disasters? There's nothing in either socialism or the free market that requires selective bail-outs. Socialism believes in bailing out without discrimination, the free market doesn't believe in bailing out at all for anyone and so doesn't discriminate either.
(The reason I'm not worried about progress is that I don't believe there's been any risk of society progressing for a long time. There have been few cultural improvements since the 1700s and the main advances in technology since then have been used more to cripple subsequent advances in culture.)
Maybe. There are problems with longer-term trends:
1) The lack of precision on data. It is easier to make graphs fit desired patterns, when there is a marked shift in precision. The graphs I've seen do NOT indicate the range of potential temperatures that would produce existant data, they assume equal precision for all data points.
2) The lack of usable data points. When using geophysical data, you cannot obtain reliable data for points that are unclear or ambiguous. Nor can you obtain data that was never recorded geophysically (for whatever reason).
3) The lack of normalization. I've seen non-normalized data - that's plentiful. (Non-normalized data contains variables other than the ones you want to study.) I have seen no significant work done to factor out duplicated variables, for example.
Hurricanes will be affected by el Nino, ocean currents, atmospheric currents, volcanos, etc. These, in turn, are driven by a far smaller number of underlying mechanisms that will affect multiple observable mechanisms. By counting the underlying mechanisms multiple times, you distort their impact.
This is one reason I detest statistical studies. If there is no establishable mechanism by which the hypothesis being tested would work, OR if there are unknowns that cannot be eliminated by n-way analysis, I cannot see anything useful in the study.
Long-term non-normalized data, where variables may be local to a specific band of time but where the presentation makes such variables impossible to detect or allow for, is worse than useless.
What do I suggest? What anyone in "hard science" would suggest - develop a hypothesis and test it. For example, cyclones are the southern hemisphere version of hurricanes. The heat conveyers within the northern and southern hemispheres have limited interaction. Thus, localized warming should affect one hemisphere more than the other.
In the early history of humanity, most humans lived in the Southern hemisphere using slash-and-burn methods of land management. Do we see any impact on cyclones in this period that do NOT match changes in hurricane patterns over the same specific timeframe?
Later humans mostly lived in the Northern hemisphere and it is these who had the largest impact on the environment. Do we see changes in hurricane patterns that are NOT reflected in cyclones?
Using the last 30 years of data, for example, have cyclones shown exactly the same variations as hurricanes, worsened by a larger margin, not worsened as much, or declined?
I don't see that in any of these studies. Those serious about DISproving should be actively more interested in supplying this data, because scientific methods dictate that the onus is on disproving something (as nothing can ever be proven).
If cyclone changes match 1:1 the changes in hurricanes, or have worsened by a greater margin, then human activity (which has varied between hemispheres) has not had significant impact, as there wouldn't be time for the impact to diffuse evenly. In all other cases, the attempt to disprove human impact has failed.
If there is no data on a successful normalized disproof (with adequate information to determine the accuracy of the disproof) then the correct conclusion is no disproof has occured.
0.07 people will die every year in the new shuttle. To guarantee this, NASA are believed to be working on ways to surgically remove arms and legs in flight.
Let us say that you build a direct equiv. in Linux. "Impossible!" I hear you cry! Well, maybe not. Not unless you've cracked into my machine and installed an MP3 of yourself.
Anyways, let us examine the different components and see how far OSS can take us. Maybe it can't go the whole journey, but if it can do some, then a hybrid solution will work.
Open Groupware, SuSE's Open Exchange and OSER will handle the Exchange part, including support for all those MS Exchange clients, such as Outlook.
That just leaves the Active Directories part. ISC's DHCP supports Dynamic DNS. However, you may want to add in DHCP2LDAP to get a good link between DHCP and BIND. OpenLDAP provides the LDAP implementation part. Kerberos and DNS are easy (although some may quibble with my choice of Kerberos version!)
Provided you're not planning on having both MS Active Directory and the above amalgam running, you should then be set to go with a comprehensive Active Directory lookalike which will interact with client systems in the same way Microsoft's software will.
The problem I found is that there's almost no way of getting from a Linux solution -to- Active Directory. If AD is present, it must be a root server, which Linux CAN pull from.
Do I recommend this kind of a setup? Probably not. The Exchange and Groupware stuff should be fine, but the Active Directory stuff isn't as coherent as it could be and I've heard of nobody who has completely replace AD with an Open Source solution, even though from a purely technical perspective it should be possible.
Slashdot Mirror
You can download the Acorn RiscOS ROMS off the Internet and Ian Bell published the source code for Elite.
That's their secret way of communicating with the Little Green Men who are telling them what to do by beaming into their heads.
Well, not until the British had lost most of its armed forces fighting alongside America against the infidels. After all, why waste ammunition on killing people who are quite happy to sacrifice themselves on your behalf?
...Cheney referred to as the President of Vice before, but it makes sense. Oh, and the President was elected. One man, one vote, with Jeb being the man.
Well, of course! It's called the Piece (of the action) Dividend and involves the militaries of the world diverting money from weapons that make for lousy TV when the reporters are too close into weapons that the news teams can only discuss with expensive CGI graphics. (The only nations that have enough dependency on space telecoms for this to matter are the Europeans. It's possible America will invade Europe at some point - I wonder which way Britain would go, if that happened - but they really don't have the means to right now. All other space powers are either too poor or too new to the game to be able to rely on such methods.)
The forest with nobody in it would.
Of course, this is pretty obvious stuff - the bleeding-edge branch of any rapid project is almost invariably going to stay as far ahead of the curve as possible, so that the software is moderately stable by the time the code hits beta-testing and beta-testers can concentrate on QC, not feature-fixing.
What I'd LOVE to see is someone porting the full KDE system to run natively on Windows, then write a layer that'll handle Windows GUI calls and DirectX through KDE. A screenshot of that would freak out so many people...
Likewise, a script has no control over how the computer (or any other computer) interprets that script. That's the main reason software companies claim exemption over lemon laws, as it is impossible to know in advance how a program will run. In consequence, if Google's HTML gets directed elsewhere, Microsoft/AOL may be able to claim that they're exempt from "restraint of trade" laws as the way the HTML is interpreted is not dictated by Google but by the recipient's OS and browser.
Oh, it should be illegal, but I'm not convinced that the courts would agree. Hell, Microsoft even convinced the courts that Windows 98 was a different OS and not Windows 95 with the browser built into it and a few bugfixes. (Microsoft was prohibited from building the browser into 95, but by calling the combined package Windows 98 the deal was circumvented.) Although Microsoft was eventually defeated over blocking DR-DOS within Windows 3.1, DR-DOS had changed hands twice and the original company had suffered crippling damage. Microsoft could easily have four, five maybe even ten years between being discovered and anything being done - by which time Google would be as dead as a doornail - and the penalties almost couldn't begin to compare with the profits MS would stand to make if that happened.
How can there be 13 errors when it isn't a friday?
Both of these would be invisible to the user, very difficult for Google to spot, but visible to advertisers and sponsors, which would potentially cripple Google's revenue stream. (This is why advertising is a lousy business model - anything that exists only on a logical level is totally mutable, making it easy for people to steal.)
The lead would deal with gamma and x-ray (your two biggest problems in space), the graphite would stop neutrons (which I don't believe would be that common, unless as secondary radiation when the elevator gets bombarded) and the iron would stop charged particles - especially beta.
You've also got to consider that dosage would be proportional to time. I doubt anyone is thinking of a space elevator that's the same speed as the service elevator in a University. (Rumor has it that the reason professors look so old is that they decided not to walk up the stairs one day...)
If your speeds are comparable to any conventional launch/re-entry, you barely need any shielding at all. IIRC, most video clips I've seen on launches do NOT show astronauts wearing helmets, but just lead-lined balaclavas. The system I'd implement would be orders of magnitude more resistant, which means you could travel orders of magnitude slower and still not suffer significantly from radiation. (Ten times the shielding would mean you'd need to only go at mach 2.6 to get a comparable radiation dose to shuttle crews. Tough, but if the elevator is possible at all, this would seem to be a very doable restriction.)
A "sealed" building is a misleading concept anyway, in this case. Smoke rises because it is hot (which is why, if you're trying to get through smoke, it is often easier if you crawl under it). So, if you had air vents at the far end of the room, into the ceiling, that had a negative pressure, you'd pull smoke away. Will this fan the flames? Probably. But smoke is a far bigger killer than flames, so if you halve the deaths from smoke but double them from fire, you're still going to win by an order or two of magnitude. It's not perfect, but I'd call that kind of reduction a good start by any standards.
Since the two biggest factors in building evacuations are smoke-related (lack of visibility and the toxicity of the smoke), these would seem to be the things to taget in any kind of structural design. The third factor is having an escape route that is unblocked, unaffected by fire or smoke, navigable and large enough to handle the density of traffic going through it. By having the escape route as a central spiral arrangement, you've got a pretty solid structure there that would be resistant to damage in a way that a conventional square arrangement is not. By having a positive pressure, you keep the smoke and fire out (the flames will be fanned towards the outside of the building, away from the escape route). In order to have a central column that can support itself AND the rest of the building by means of ribs, you'd need something that was pretty large, which means you'd have a very wide staircase, which is exactly what you want for large-scale evacuations.
(One of the problems with having many small staircases is that a given staircase will choke rapidly, making escape for those in it much harder. Another is that those NOT on that staircase have to waste valuable time hunting for one clear enough to get down. Having fewer, substantially larger, staircases would reduce latency by eliminating seek time and preventing I/O blocking by having much fatter pipes. (In computing, a single gigabit pipe is generally going to do better than having a hundred ten megabit pipes that are channel bonded together. Since flows are flows, it should make little difference if we apply the principles to escape methods. You want to have a system that can handle randomly-occuring bursts at maximum capacity without choking, which means you want the smoothest flows possible, which typically means a very few very fat pipes for the backbone.)
The Shuttle gets the benefit of the ceramic heat-proof tiles, which would be unusable on an elevator cord, as the tiles are way too fragile to survive having a huge elevator clamped onto them. They'd crush. The tiles are also highly toxic, which makes getting out of the elevator somewhat awkward.
The potential difference between the ends of the cord is the biggest technical problem - you're going to get a potential difference great enough to simply destroy most substances at a fraction of the length required. You're going to have to solve that problem before you're going to get very far.
Building from space and dropping the cord would be disasterous - air resistance from a vertical plunge would destroy it. You're better off attaching the cord to a propellent-free vehicle and firing it up, as you'd have fewer heating problems. Air currents might be a problem (such as pushing against the cord, resuling in the vehicle plunging uncontrollably towards the ground).
Do I think it's better than NASA's solution? Oh, by a long way. I don't think it'll work, but it would advance technology considerably even if it fails to achieve its primary goal. NASA's solution won't advance a damn thing, even if it succeeds.
Personally, I'd have thought it simpler to have a central spiral staircase in the building, acting as a sort of spinal cord. You then create a positive pressure in the staircase, such that smoke in the building will always blow AWAY from it, never towards it. (This prevents the chimney effect that causes so many disasters in tall buildings with continuous staircases.)
By locking everything onto that staircase as ribs, you should get a stronger structure than using the current pile-of-boxes approach.
This will only take one reactor core to power, but Vista's specs say it will require a dual-core system, minimum.
"Y'all Yurocats canfirmed that there tha competition kermission is considerin' that there complaints, y'all. Ya hear?"
The change in sensitivity estimates means that the slash-and-burn agriculture common in early history may have been enough to create a measurable impact.
For that matter, who gets to decide what a bug is, rather than a "feature"? The DRM in the current version of the Acrobat format allows you to run embedded Javascript with no access controls. This is arguably an exploit, but Adobe would doubtless classify it as a feature, as it means you cannot circumvent DRM by turning the Javascript off.
Secondly, the numbers are not directly comparable, as Mozilla is standalone whereas IE is built into the OS. (This is important, as integration means that bugs that are strictly in the OS could be exploited through the web browser, without it being a web browser bug.)
Thirdly, there are deals over the reporting of security holes in software, whereby a report can be held back until a patch has been readied. This means that even "unconfirmed" (but reported) bugs by security vendors may be capped by the manufacturer. (Not always, even with those manufacturers who do this, but it does introduce uncertainty.)
Finally, Mozilla is cross-platform but bugs may not always be. Any buggy code that is OS-specific, for example, or any bug which relies on some OS-specific or library-specific bug in order to be exploitable, may only affect certain platforms as a result.
There is a second part to this one! It is also possible to have one bug that appears in multiple forms, but only one form per OS (due to OS-specific characteristics). Does it count as one bug or as many? (Remember, it still only takes one form in a given OS, but because of dependencies, changes in some way between different operating systems.)
Now, you can argue that many of the above are very hypothetical and do not apply in this specific study. Perhaps that is true, but the point is that unless you have rigorous controls on how you produce the statistics, the uncertainties are bound to be comparable to the number of incidents, making the statistics worthless.
And that is my point. If the possible variance in the number of actual bugs (reported or otherwise) gets to be comparable to the number of bugs reported, then the reports mean nothing. The actual number of bugs encountered could range from zero to infinity and the stats would still be "correct".
Ideally, the security companies would produce sufficient additional information to demonstrate the confidence they have in the values produced as opposed to simply citing the numbers but not really backing them up with anything concrete.
Where uncertainty is required by the vendor, then publish a range or some other indicator of how many unpublishable but reported bugs are believed to exist. (Since there is no guarantee that the unpublishable data is circulated with security vendors, an accurate figure may not be producable at all.)
(Yeesh, that's worse than my original post!)
The bulk of greenhouse gasses, in early human civilization, were released in the southern hemisphere. The bulk of the greenhouse gasses released in later civilization were released in the northern hemisphere.
The air from the two hemispheres mixes, but relatively slowly. In consequence, what you should expect from man-made causes is an effect that ONLY occurs within one hemisphere for a prolonged period of time and then gradually extends into the other hemisphere.
Mixing between hemispheres over periods in which air or water circulation was disrupted for whatever reason, provided it was for a long enough period of time, should result in a much greater disparity between the two hemispheres in atmospheric behaviour, assuming that to be a significant influence.
So, we should expect that hurricanes would have become marginally worse in the southern hemisphere relative to the northern hemisphere, from the dawn of civilization up until the start of the mass migration into the northern hemisphere.
By measuring the two hemispheres independently, as they're largely independent systems with a common source of input from the natural world, and then taking the ratio of major storm systems between the two, you should get a figure that is slightly more in favour of the northern hemisphere to the south because there's more landmass and therefore less reflection of solar energy.
Over the early human civilization, this number should start creeping towards 1:1, or even swinging a little in favour of the south having more severe weather.
Once the northern hemisphere was occupied, the ratio should swing the other way, first back to the "normal" ratio and then more and more towards the north as the impact of humans escallated.
Because this comparison is of a ratio, it eliminates variations caused by solar input, volcanos (where the impact is so great that both hemispheres are affected rapidly), global climate changes (ice ages, etc), and so on. The only things to affect the ratio will be things that don't cross oer the equator so much.
If, as I've suggested, the change migrates, then you also eliminate the possibility of something that is static that disrupted climate.
Finally, if such a migration occurs at about the same time as human migration to the north, you'd have fairly strong evidence that humans were involved in the migration of the cause.
If you see any new concrete bridges going up near the Redmond campus, a discontinued blog and a mysterious cavity showing up when using GPR, we will know how seriously Microsoft takes criticism.
It is because of companies trying to squeeze every last drop out of the residual value that copyright has been extended in time and coverage. In consequence, I have a hard time being sympathetic. If you pursue a commercial model that you know, by definition, is beither tennable nor stable, then why should the rest of society foot the bill?
Did bookshops bail out the dot-com failures? No? Then why should computer companies bail out bookshops who are self-created disasters? There's nothing in either socialism or the free market that requires selective bail-outs. Socialism believes in bailing out without discrimination, the free market doesn't believe in bailing out at all for anyone and so doesn't discriminate either.
(The reason I'm not worried about progress is that I don't believe there's been any risk of society progressing for a long time. There have been few cultural improvements since the 1700s and the main advances in technology since then have been used more to cripple subsequent advances in culture.)
1) The lack of precision on data. It is easier to make graphs fit desired patterns, when there is a marked shift in precision. The graphs I've seen do NOT indicate the range of potential temperatures that would produce existant data, they assume equal precision for all data points.
2) The lack of usable data points. When using geophysical data, you cannot obtain reliable data for points that are unclear or ambiguous. Nor can you obtain data that was never recorded geophysically (for whatever reason).
3) The lack of normalization. I've seen non-normalized data - that's plentiful. (Non-normalized data contains variables other than the ones you want to study.) I have seen no significant work done to factor out duplicated variables, for example.
Hurricanes will be affected by el Nino, ocean currents, atmospheric currents, volcanos, etc. These, in turn, are driven by a far smaller number of underlying mechanisms that will affect multiple observable mechanisms. By counting the underlying mechanisms multiple times, you distort their impact.
This is one reason I detest statistical studies. If there is no establishable mechanism by which the hypothesis being tested would work, OR if there are unknowns that cannot be eliminated by n-way analysis, I cannot see anything useful in the study.
Long-term non-normalized data, where variables may be local to a specific band of time but where the presentation makes such variables impossible to detect or allow for, is worse than useless.
What do I suggest? What anyone in "hard science" would suggest - develop a hypothesis and test it. For example, cyclones are the southern hemisphere version of hurricanes. The heat conveyers within the northern and southern hemispheres have limited interaction. Thus, localized warming should affect one hemisphere more than the other.
In the early history of humanity, most humans lived in the Southern hemisphere using slash-and-burn methods of land management. Do we see any impact on cyclones in this period that do NOT match changes in hurricane patterns over the same specific timeframe?
Later humans mostly lived in the Northern hemisphere and it is these who had the largest impact on the environment. Do we see changes in hurricane patterns that are NOT reflected in cyclones?
Using the last 30 years of data, for example, have cyclones shown exactly the same variations as hurricanes, worsened by a larger margin, not worsened as much, or declined?
I don't see that in any of these studies. Those serious about DISproving should be actively more interested in supplying this data, because scientific methods dictate that the onus is on disproving something (as nothing can ever be proven).
If cyclone changes match 1:1 the changes in hurricanes, or have worsened by a greater margin, then human activity (which has varied between hemispheres) has not had significant impact, as there wouldn't be time for the impact to diffuse evenly. In all other cases, the attempt to disprove human impact has failed.
If there is no data on a successful normalized disproof (with adequate information to determine the accuracy of the disproof) then the correct conclusion is no disproof has occured.
0.07 people will die every year in the new shuttle. To guarantee this, NASA are believed to be working on ways to surgically remove arms and legs in flight.
Anyways, let us examine the different components and see how far OSS can take us. Maybe it can't go the whole journey, but if it can do some, then a hybrid solution will work.
Open Groupware, SuSE's Open Exchange and OSER will handle the Exchange part, including support for all those MS Exchange clients, such as Outlook.
That just leaves the Active Directories part. ISC's DHCP supports Dynamic DNS. However, you may want to add in DHCP2LDAP to get a good link between DHCP and BIND. OpenLDAP provides the LDAP implementation part. Kerberos and DNS are easy (although some may quibble with my choice of Kerberos version!)
Provided you're not planning on having both MS Active Directory and the above amalgam running, you should then be set to go with a comprehensive Active Directory lookalike which will interact with client systems in the same way Microsoft's software will.
The problem I found is that there's almost no way of getting from a Linux solution -to- Active Directory. If AD is present, it must be a root server, which Linux CAN pull from.
Do I recommend this kind of a setup? Probably not. The Exchange and Groupware stuff should be fine, but the Active Directory stuff isn't as coherent as it could be and I've heard of nobody who has completely replace AD with an Open Source solution, even though from a purely technical perspective it should be possible.