I was responding to a post that implied that this failure could cause a midair collision. It could not. I didn't address the possible economic impact of the failure because that wasn't the topic I was responding to.
But, since you brought it up, what would be the economic impact of fixing it so it could never, ever fail under any circumstances? Moreover, is that even possible?
Keep in mind that flight safety stuff is standalone. Each zone has their own RADAR, their own control systems, and is a self-contained entity. Most of the handoff is (or can be) done from controller-to-pilot. This is by design, both for safety and efficiency. There's no compelling reason to integrate the systems, and it's not worth the added complexity and risk of failure.
Safety gear needs to tell you where planes are, give you warnings if two planes start converging on course, and give you ways to communicate those issues to an airplane. Once an airplane flies outside your zone of control, it's not your problem any more, so your system doesn't even need to be aware of those aircraft.
Flight planning is, by its nature, integrated across the country. Airway allocation needs to be done as a coordinated national function, not a series of zones. Flight Planning is a separate entity within the FAA. They send their data to the individual controllers, but they don't really need to. Flight Planning exists to reduce or eliminate congestion (clumps of aircraft close together) so the controllers have an easier time managing the flow of traffic (and therefore you can have more planes in the air at a time).
The hardware and software involved in planning are far more integrated and therefore complex. By its nature the system is subject to additional points of failure as a result.
Then you add funding and priorities to it, and you accept that an occasional failure of the planning system isn't going to end up with anyone dead. So you do your best, but accept that you'll probably have a failure from time to time because making the system completely reliable means spending probably more money than is lost by everyone delayed.
So, in order to avoid the chance of missing your $1M meeting, how much additional would you like added to each airline ticket everyone buys every day? Because $50 probably isn't going to even start covering it, and if you make everyone pay $50 on each and every airline ticket to reduce the chances of a once-in-a-year flight delay, it'll never get passed. This isn't even a leading cause of delays.
There are too many other delays for too many other reasons for this one to reach that level of spending priority. Again, even if making the system completely immune to failure is possible.
Actually, Google Earth does have terrain information. It's not terribly accurate, but you can turn on the terrain view and have the mountains stick up and the valleys drop down. Misalignments are humorous, and it's still a 2D image mashed down onto a 3D projection, but in some places it's quite stunning.
But yes, I'm sure they used something FAR better than Google Earth.:)
Even if it's fixed, there will still be delays for a while. There are probably tons of flights that are still awaiting clearance and the requests are being dealt with as quickly as safely possible. Meanwhile, a normal load of requests is still coming in, and those go into queue as well.
Trouble with things like flight planning is that they are, well, planning. If they go down, the manual process can't keep up with the load, and a queue develops. Once the system comes back up, it's gotta munge through the queue and get all the planes that have been waiting for clearance in the air.
And the skies can only handle so much traffic - you can't have infinite numbers of planes in the sky at once. So there will be a period where takeoffs will be done pretty close together, up to the point where the flying lanes are at max safe capacity. Max safe capacity is higher than normal capacity, but it'll still take a while to get all those delayed flights going, and the flights that are just now at this moment getting ready to go will be delayed as a result.
The net result of this is the same as a construction zone on a highway - you have a large stretch of highway with traffic backed up in it (planes waiting to take off) followed by a stretch of highway that almost empty. If you pull the barriers, it will still take a while for the empty stretch of highway to fill up with cars again, and the cars at the back of the line still have a long wait ahead before they can get up to speed.
Sorry to hear that. But, as the old saying goes, "it's better to be DOWN HERE desperately wishing you were UP THERE, than UP THERE desperately wishing you were DOWN HERE."
Considering that this did not affect the development of flight plans, only delayed them, I'd rip this back out of the category of "safety critical".
Online development of flight plans is much faster than offline. But that's precisely what makes the offline ones safe - as you delay the development of flight plans you also reduce the number of planes being cleared for takeoff at the same time. Once the flight planning software goes back online, you can start granting flight plans quickly again and get traffic volumes back to normal.
And it's a bit of a stretch to assume a risk of a collision even in the complete absence of flight planning. ATC, Radar, airplane internal collision avoidance, and pilot eyeballs are all unaffected by this. The only thing this could possibly do is put two planes in the vicinity of each other, but even that is unlikely as the sky isn't "the wild west" - it's carved up into clearly-defined highways with speed limits and defined routes which are all used in flight planning. So if you have two planes in the vicinity of each other, they are going in the same direction at roughly the same speed, so there's TONS of time to react.
And the first precaution, as we've seen here, is to reduce the number of clearances. Arguably, this makes the actual flying safer, since there are fewer planes up there for ATC to have to track and communicate with.
Sorry, this is flight planning/scheduling software. This is the system by which airliners are told what route they are to take when they finally get their flight clearance.
The primary reason this has not received "oh my god the sky is falling" priority is because, well, it isn't. Nor are shiny metal tubes blasting through the sky at 500 miles an hour going to smash into each other because of this. People will be inconvenienced and that's regrettable and needs to be fixed, but this is not a safety issue.
- Radar control systems: Unaffected.
- Air Traffic control: Unaffected.
- Communications: Unaffected.
- Landings: Unaffected.
- Any flights already in progress: Unaffected.
- Ground control: Unaffected.
- Passenger Safety: Unaffected.
This only delays the granting of flight clearance. The planes that are inconvenienced by this are safely on the ground, and the effect is that they stay on the ground longer than they should. Again, this is regrettable, but not fatal. There is no plausible scenario that would lead from this to a failure of traffic control. In fact, with fewer planes in the sky, you could argue that flying is actually safer (for those people who are lucky enough to have gotten clearance, of course!).
In the medical field, this would be a failure of the system that the receptionist uses to schedule your next appointment. In the automotive analogy, this would be a failure of your garage door opener. In the heart monitor analogy, there isn't even an analogy because heart monitors don't have (as far as I know) any non-critical systems.
That's an excellent point. I'm assuming the web developer, however, would not have access to the API directly.
If they do, then, damn, talk about vendor lock-in. IE9 would become the new IE6, with anyone stupid enough to deploy its full feature set locked to only having customers who have IE9.
But I have to assume that Redmond learned their lesson on this one, and has insulated the DirectX API calls to "stuff that happens in rendering standard HTML", and not "web developer can send DirectX commands straight to the graphics engine".
Because if it's the latter, I don't WANT better performance. More importantly, I don't want some Nigerian web developer having a passthru to DirectX via my browser. ActiveX is bad enough...
The problem is not "better performance" the problem is the means by which Microsoft aims to eke out that "better performance". Some programmers go about that by reducing and/or optimizing the codebase. Microsoft's approach is to consume more system resources, and, frankly, appear to be trying to optimize something that needs no optimization.
And in order to accomplish this, they are proposing to have IE9 use DirectX for rendering, which will make the rendering engine larger and consume more RAM, and at the same time your GPU will be running harder to accomplish better performance on the least bottlenecked portion of page rendering - the screen paint. I can't help wondering - how would something like this run on anything-but-top-end hardware? And what happens if you DON'T have top-end stuff?
If and when 3D web pages (true 3D web pages) come to pass, Microsoft will be ready. I'll grant them that. But adding a GPU interface layer to spiff up the screen fonts seems to be completely not worth the overhead. Microsoft claims to be the only company using the GPU, and that's true, but other browsers don't have a font-rendering problem. So, I think the pertinent question is "why is Microsoft the only company that FEELS THE NEED to engage the GPU to solve this problem?" Others have solved it without resorting to (obligatory car analogy) adding go-fast stripes and a nitrous-oxide kit.
Now, having said that, there ARE substantial improvements claimed in the article, ones that really mean something. Their claims on Javascript, for example, are impressive. Instead of 1/4 the speed of Firefox, they are targeting better than half the speed. We can at least give them the "most improved" tag they really deserve, though they still have substantial catching up to do in that area. But, they are improving things and that's good.
Their Acid3 tests also show significant improvements. They are severely lagging behind the others, but compared to what they have today it's a significant improvement.
There are a LOT of things they have left to do, including true PNG support, that would be a lot more important to many of us than gobbling up GPU resources to solve a problem that doesn't really appear to exist anywhere else. It's innovative, I'll grant them that, and maybe it'll prove to be a good design decision. I remain skeptical at this time.
We had the same problem in one of our buildings for a while - putting in Verizon-specific repeaters. Somehow, they interfere with other signal. Imagine that. The AT&T repeater never borked Verizon signal, but once you put in the Verizon repeater even the AT&T repeater wasn't enough to get signal.
Rip 'em out, replace 'em with a set of Wilson or other third-party non-carrier-specific repeater, Life Is Good.
Verizon's map is a coverage area map. They paint broad swaths of area where they have towers, but don't show any gaps in signal. Even up here in Verizon country (New England), I found that Verizon has plenty of dead zones where I don't get signal yet I'm in an area of the map that says I should. Verizon just takes each tower (I guess) and paints a circle around it with the theoretical diameter that the tower could reach.
AT&T's map, as far as I can see, is an actual signal map If I zoom in on it, I see predicted levels of signal and gaps in coverage that correspond roughly with the gaps I actually experience when I'm going places. It's not perfectly accurate, of course, but at least it makes the apparent attempt to be honest about actual signal. I don't know how they do it - perhaps they simply check terrain in Google Earth and look for landscape that "shadows" a tower. But whatever - I find it's very rare for me to lose signal in areas where the AT&T map shows coverage.
So, while Verizon may technically be accurate in stating that they have better "3G coverage" nationwide, I bet if you actually compared signal (that is, areas where you can actually get a 3G signal, and not areas within x miles of a tower regardless of terrain), Verizon's map would look a whole lot less thorough.
Verizon has the better 3G coverage. Fine, I get that. Of course, I don't have a 3G capable phone so I really don't care. But I get that it is important to some people. Verizon even has (marginally) better Voice/non-3G Data coverage here in New England.
But I had no way of honestly comparing them based on the coverage maps. AT&T showed me incomplete coverage that matched my real-world experience with my prepaid Go! phone. Verizon showed absolute 100% coverage everywhere which certainly did NOT match our experience with my wife's Verizon phone.
Example: My mother lives in a small town on the coast. When I go to her house, coverage is VERY spotty - you basically have to be near a window to get a bar or two. Verizon and AT&T have the exact same actual signal - very low (1-2 bars) and you have to pretty much be at a window standing still to make a call and have any hope of completing a conversation. My wife's Verizon phone and my AT&T phone were pretty much identical in performance.
The maps tell a very different story. AT&T shows my mother's house as "no coverage" along with a good chunk of the peninsula she lives on. Verizon shows the entire peninsula she lives on with full-on 3G coverage, no gaps whatsoever. Most of the peninsula has *no coverage of any kind* with AT&T or Verizon.
I finally concluded that I'd rather be told the truth, and when my company offered the choice of carriers for my Crackberry I went with AT&T. It didn't hurt, of course, that Verizon also locks out the GPS on the models we had, and AT&T allows me to use it (Verizon CLAIMED you could, but then they told you afterward that you had to buy the $10/month TeleNav service and even then you STILL wouldn't be allowed to use the GPS with anything other than TeleNav, Blackberry Maps, and Google Maps).
I have no particular love for AT&T, but at least they appear to be making an effort at honesty about their signal coverage, and when they sell me a phone with a feature installed they let me use the feature.
If I manage 10 computers and need to install new software for everyone, I'll bop on down to their desks and install it at night, no biggie. I neither want nor need this turned on.
If I manage 10,000 computers, I'm never going to have the staff to do that. So I'm going to set up an internal repository and make approved applications available on it. Then my Linux image could have this feature turned on, along with a customized list of "approved signing authorities" which would be MY repository server (or servers - I might have one repo for finance apps and another for all users, for example).
If the company approves an application, I put it on the internal repo and tell users it's available if they want/need it.
And if an individual user needs something special, I can still use root to install it for them.
Yes, because as everyone knows, whenever ANYONE speaks about Linux, it's the SAME person who made another previous statement about Linux.
UAC is an excellent attempt at a Windows implementation a proper security model (temporary escalation of authority for a specific task, with prompting). Personally my only complaint about UAC was that it took Microsoft so long to finally come around to something like it. I run XP as a limited user, and it's very frustrating to see all the software that has been written for Windows that assumes you are running as Admin simply because that's the Windows XP default.
And, yes, I'm clearly and keenly aware that Microsoft is not responsible in any way for the laziness or incompetence of third party developers who write code that runs on their OS. But it does point back to the whole issue that's plagued Microsoft all along - security was ignored for way too long in Redmond, and continued as an oft-ignored afterthought well after they had gained a reputation for writing insecure code. I will give them credit - once they finally extracted cranium from anus and got the clue meter off zero, they made a relatively impressive turnaround in security in a very respectable amount of time.
It depends on your environment. For an individual user, you'd want sudo or su and you'd want to be prompted for each install. And that's a good thing.
But in a large corporate environment, I might want to make a bank of internal applications available (similar to Microsoft's "Run Advertised Programs"). I could configure all of my corporate desktops to only recognize the signing authority of a repository I own, then any of my users can install anything they want off that repository. But installs of things not on the "approved" list and therefore in the repository require root access.
However, this configuration setting was still a Bad Move on RedHat's part. If a corporation wants to allow this, they'll probably also want to think about the list of signing authorities they want to use. So this should be OFF by default and if an administrator wants to turn it ON they'd need to take action (and would presumably know what they are doing and why).
As a default, it doesn't, because if you're a corporation wanting to extend this authority you'll almost certainly want to spend some time configuring the trusted authority list so you can host "approved" applications on an internal server.
Fortunately, this is a policy setting and not a code change. RedHat should change the default back to "requires root", though, because anyone who wants to change this policy should know what they are doing and make the appropriate configuration changes to control (or not) the applications that can be installed.
No, there is a significant difference between "running as Admin" and "installing a signed application without requiring root (Linux's Admin) authority".
The amount of authority granted depends on how many signing authorities you have decided to trust. If you trust only a server under your own control, for example, this could be really useful within an organization to allow users to install company-authorized packages without having to run around and install everything for everyone, while still preventing average users from doing anything to the machine.
I don't agree with this change in RedHat, but it is (fortunately) a policy change and not a programming change. In other words, it's easy for any machine owner to change the policy (which can, by the way, only be done as root) and require that all software installs be done by root only (which was the old default). In my opinion, this default should be changed back, and those people who want to send signed packages out within their organizations can change the policy.
A regular RedHat user still cannot do things like reformat the hard drive, change operating system files or core system configurations, access any data but their own, etc. Similar to a "Limited" user account in Windows (but the difference is that Microsoft, by default, has traditionally made all accounts Admin, and a lot of software vendors have come to depend on that so making a Limited user is an exercise in deep frustration in Windows).
2. could not agree more. Direct heating of water is the most efficient way to get, well, hot water.;) In fact, such systems are becoming popular here in the Northeast. We don't have optimal sunlight, but at 16 cents a kwh, we sure have expensive enough electricity to justify using what little Sun we get to our advantage!
Off-grid is a decent use of solar. However, generation need not be at the household level, and storage need not be in the form of batteries.
An experiment was proposed here in Maine that was intriguing. A company wanted to dig a gigantic hole in the ground where the Maine Yankee nuclear plant used to be. That hole would be several hundred feet deep, adjacent to the ocean.
Interestingly enough it was designed to be, in essence, a battery.
When power was needed, let the hole fill up with seawater, and capture the energy as electricity to feed into the grid. When excess power was available, use it to pump water back out of the hole.
No battery technology to deal with - you're storing the power as potential energy. As long as you keep the hole empty, you have a pretty massive amount of potential energy that can be converted to electricity.
The beauty of that scheme would be for tidal power, where you have very predictable points in the cycle where you cannot generate power (slack tide) and predictable points where you generate WAY over average power (half-tide when water is really moving fast). So you use some of the power at half-tide to generate power to empty the hole, then at slack tide use that to generate power while the tide is turning around.
Could also be useful for wind power, though when the wind goes out you never know when it'll be back. Solar power could be a good supplemental source for this, though you'd have to have a very large hole to get through long cloudy periods around here.
For our area, tidal for electrics and solar for direct heat (house heating, hot water) would probably be our ideal mix, maybe with a little photosolar at the house level but connected to the grid. Perhaps with one of those holes in the ground here and there to get through the bad spots where we don't get a lot of Sun (we call them "Mud Season", most people call them "Spring").
6. Nuclear may be part of the discussion, pretty much anywhere, but now we get back to the whole point of this whole thread. The claim from CERN that we may have exceeded "Peak Nuke".
The elephant in the room in EVERY discussion about peak oil, climate change, alternative fuels, etc has basically been "if the anti-nuke groups would just get over their fear of nuclear power, we could dot the landscape with silos and everyone would get all the power they need." Fair enough, and with enough nuclear material we could.
Nuclear power has always been a panacea that, if we could just get over our fear of it, could bail our asses out of a shortage.
Except, now, according to CERN, it's not. We're already overdrawing that account by using up all our disposed nuclear weapons for fuel.
Now, that's a damned good use for old bombs if you ask pretty much anyone, but once we run out of them what do we do?
Net effect: Slight increases in development effort.
As I understand it, you can install additional functionality into Firefox in one of two ways:
1. Use the built-in installer. This is the "countdown box" that confirms that you want to install what the software is asking to install. It checks compatibility, and offers the capability of checking for updates and validating compatibility when a new version of Firefox gets installed (and disabling software that has NOT been tested with that specific flavor of Firefox).
2. Throw a file into a plugins or addons directory and Firefox will look for it and load it unconditionally next time it starts.
Sounds to me like they are going to reduce or eliminate #2.
So, as a developer, you'll probably have to package your plugins into a Firefox install package rather than an old Netscape-style plugin. You'll build that package specifying what versions of Firefox you have tested your plugin with, and the user will be informed that a new plugin wants to be installed.
Firefox could also fix this by scanning for all plugins and enumerating the ones that the user has identified as "safe", while prompting for any new ones that aren't in the database yet (or that have had their version numbers or file dates changed).
But that's more of a patch - the real solution is to protect the directory and only allow installs through the Firefox UI. I would be very curious to find out how they intend to protect the directory, though maybe they are simply ignoring anything "unexpected" that happens to be sitting there.
Possibly, but compare that to what we do now for electricity.
What's the thermal impact of a 100-acre solar plant as opposed to that of the portion of uncaptured soot generated by a coal fired power plant? And how much additional heat will be retained by the now-released CO2?
How does a rise in local air temperature compare to, say, raising the local water temperature along the shoreline to cool a nuclear plant?
No matter what we do to generate power, we are going to have an environmental impact. The most efficient way to "generate" power is to not use it, but there are practical limits to that.
So we need to generate power. Which source is least impactful and (very important) isn't going to run out on us?
Of course, if you made a solar array large enough that the heat creates a thermal and puts a permanent cloud over the array, I think you'd break a hole in the space/irony continuum. The problem would be self-correcting (shade cuts the heat allowing the cloud to dissipate) but you're getting a whole lot less power output during the dissipation phase.
It could lead to some interesting solutions, though - putting some sort of wind generator to capture some of the energy in the rising hot air and use that as well.
Actually, if we could come up with something like that, Washington DC could probably power most of the Eastern Seaboard.
I find it hard to watch movies like this one. I cannot suspend reality enough. Yet, I watch Star Trek where humanity has ended all internal conflict. Go figure.
and some of those holidays are only on certain classes of items, up to a certain amount, etc. Fun!
The first year Maine added Use Taxes, I decided to itemize. I had about $500 in receipts, give or take. It took me FOUR FREAKING HOURS to go through the receipts and figure out what tax rate applied to each item.
Now I just check the Alternative Minimum tickybox on my tax form, and to hell with it. My time's worth more than that.
Slashdot Mirror
It's OK. I knew using a severely overused Slashdot meme could backlash.
And it's been modded "Funny" at the moment.
But thanks for the kind words.
I was responding to a post that implied that this failure could cause a midair collision. It could not. I didn't address the possible economic impact of the failure because that wasn't the topic I was responding to.
But, since you brought it up, what would be the economic impact of fixing it so it could never, ever fail under any circumstances? Moreover, is that even possible?
Keep in mind that flight safety stuff is standalone. Each zone has their own RADAR, their own control systems, and is a self-contained entity. Most of the handoff is (or can be) done from controller-to-pilot. This is by design, both for safety and efficiency. There's no compelling reason to integrate the systems, and it's not worth the added complexity and risk of failure.
Safety gear needs to tell you where planes are, give you warnings if two planes start converging on course, and give you ways to communicate those issues to an airplane. Once an airplane flies outside your zone of control, it's not your problem any more, so your system doesn't even need to be aware of those aircraft.
Flight planning is, by its nature, integrated across the country. Airway allocation needs to be done as a coordinated national function, not a series of zones. Flight Planning is a separate entity within the FAA. They send their data to the individual controllers, but they don't really need to. Flight Planning exists to reduce or eliminate congestion (clumps of aircraft close together) so the controllers have an easier time managing the flow of traffic (and therefore you can have more planes in the air at a time).
The hardware and software involved in planning are far more integrated and therefore complex. By its nature the system is subject to additional points of failure as a result.
Then you add funding and priorities to it, and you accept that an occasional failure of the planning system isn't going to end up with anyone dead. So you do your best, but accept that you'll probably have a failure from time to time because making the system completely reliable means spending probably more money than is lost by everyone delayed.
So, in order to avoid the chance of missing your $1M meeting, how much additional would you like added to each airline ticket everyone buys every day? Because $50 probably isn't going to even start covering it, and if you make everyone pay $50 on each and every airline ticket to reduce the chances of a once-in-a-year flight delay, it'll never get passed. This isn't even a leading cause of delays.
There are too many other delays for too many other reasons for this one to reach that level of spending priority. Again, even if making the system completely immune to failure is possible.
So, a Beowulf cluster of bathroom mirrors, then?
Actually, Google Earth does have terrain information. It's not terribly accurate, but you can turn on the terrain view and have the mountains stick up and the valleys drop down. Misalignments are humorous, and it's still a 2D image mashed down onto a 3D projection, but in some places it's quite stunning.
But yes, I'm sure they used something FAR better than Google Earth. :)
Even if it's fixed, there will still be delays for a while. There are probably tons of flights that are still awaiting clearance and the requests are being dealt with as quickly as safely possible. Meanwhile, a normal load of requests is still coming in, and those go into queue as well.
Trouble with things like flight planning is that they are, well, planning. If they go down, the manual process can't keep up with the load, and a queue develops. Once the system comes back up, it's gotta munge through the queue and get all the planes that have been waiting for clearance in the air.
And the skies can only handle so much traffic - you can't have infinite numbers of planes in the sky at once. So there will be a period where takeoffs will be done pretty close together, up to the point where the flying lanes are at max safe capacity. Max safe capacity is higher than normal capacity, but it'll still take a while to get all those delayed flights going, and the flights that are just now at this moment getting ready to go will be delayed as a result.
The net result of this is the same as a construction zone on a highway - you have a large stretch of highway with traffic backed up in it (planes waiting to take off) followed by a stretch of highway that almost empty. If you pull the barriers, it will still take a while for the empty stretch of highway to fill up with cars again, and the cars at the back of the line still have a long wait ahead before they can get up to speed.
You and dtmos (see post further down in this thread) should get together for a beer. You're both stuck in Atlanta, and it's after noon. :)
Slashdotters meeting in person? Whoda thunk it. LOL.
Sorry to hear that. But, as the old saying goes, "it's better to be DOWN HERE desperately wishing you were UP THERE, than UP THERE desperately wishing you were DOWN HERE."
Considering that this did not affect the development of flight plans, only delayed them, I'd rip this back out of the category of "safety critical".
Online development of flight plans is much faster than offline. But that's precisely what makes the offline ones safe - as you delay the development of flight plans you also reduce the number of planes being cleared for takeoff at the same time. Once the flight planning software goes back online, you can start granting flight plans quickly again and get traffic volumes back to normal.
And it's a bit of a stretch to assume a risk of a collision even in the complete absence of flight planning. ATC, Radar, airplane internal collision avoidance, and pilot eyeballs are all unaffected by this. The only thing this could possibly do is put two planes in the vicinity of each other, but even that is unlikely as the sky isn't "the wild west" - it's carved up into clearly-defined highways with speed limits and defined routes which are all used in flight planning. So if you have two planes in the vicinity of each other, they are going in the same direction at roughly the same speed, so there's TONS of time to react.
And the first precaution, as we've seen here, is to reduce the number of clearances. Arguably, this makes the actual flying safer, since there are fewer planes up there for ATC to have to track and communicate with.
Sorry, this is flight planning/scheduling software. This is the system by which airliners are told what route they are to take when they finally get their flight clearance.
The primary reason this has not received "oh my god the sky is falling" priority is because, well, it isn't. Nor are shiny metal tubes blasting through the sky at 500 miles an hour going to smash into each other because of this. People will be inconvenienced and that's regrettable and needs to be fixed, but this is not a safety issue.
- Radar control systems: Unaffected.
- Air Traffic control: Unaffected.
- Communications: Unaffected.
- Landings: Unaffected.
- Any flights already in progress: Unaffected.
- Ground control: Unaffected.
- Passenger Safety: Unaffected.
This only delays the granting of flight clearance. The planes that are inconvenienced by this are safely on the ground, and the effect is that they stay on the ground longer than they should. Again, this is regrettable, but not fatal. There is no plausible scenario that would lead from this to a failure of traffic control. In fact, with fewer planes in the sky, you could argue that flying is actually safer (for those people who are lucky enough to have gotten clearance, of course!).
In the medical field, this would be a failure of the system that the receptionist uses to schedule your next appointment. In the automotive analogy, this would be a failure of your garage door opener. In the heart monitor analogy, there isn't even an analogy because heart monitors don't have (as far as I know) any non-critical systems.
"Mooooo"
Oh, sorry, I pronounced that wrong.
"Gnuuuuuu..." :)
That's an excellent point. I'm assuming the web developer, however, would not have access to the API directly.
If they do, then, damn, talk about vendor lock-in. IE9 would become the new IE6, with anyone stupid enough to deploy its full feature set locked to only having customers who have IE9.
But I have to assume that Redmond learned their lesson on this one, and has insulated the DirectX API calls to "stuff that happens in rendering standard HTML", and not "web developer can send DirectX commands straight to the graphics engine".
Because if it's the latter, I don't WANT better performance. More importantly, I don't want some Nigerian web developer having a passthru to DirectX via my browser. ActiveX is bad enough...
NOT (Better performance != bloated) at least.
The problem is not "better performance" the problem is the means by which Microsoft aims to eke out that "better performance". Some programmers go about that by reducing and/or optimizing the codebase. Microsoft's approach is to consume more system resources, and, frankly, appear to be trying to optimize something that needs no optimization.
And in order to accomplish this, they are proposing to have IE9 use DirectX for rendering, which will make the rendering engine larger and consume more RAM, and at the same time your GPU will be running harder to accomplish better performance on the least bottlenecked portion of page rendering - the screen paint. I can't help wondering - how would something like this run on anything-but-top-end hardware? And what happens if you DON'T have top-end stuff?
If and when 3D web pages (true 3D web pages) come to pass, Microsoft will be ready. I'll grant them that. But adding a GPU interface layer to spiff up the screen fonts seems to be completely not worth the overhead. Microsoft claims to be the only company using the GPU, and that's true, but other browsers don't have a font-rendering problem. So, I think the pertinent question is "why is Microsoft the only company that FEELS THE NEED to engage the GPU to solve this problem?" Others have solved it without resorting to (obligatory car analogy) adding go-fast stripes and a nitrous-oxide kit.
Now, having said that, there ARE substantial improvements claimed in the article, ones that really mean something. Their claims on Javascript, for example, are impressive. Instead of 1/4 the speed of Firefox, they are targeting better than half the speed. We can at least give them the "most improved" tag they really deserve, though they still have substantial catching up to do in that area. But, they are improving things and that's good.
Their Acid3 tests also show significant improvements. They are severely lagging behind the others, but compared to what they have today it's a significant improvement.
There are a LOT of things they have left to do, including true PNG support, that would be a lot more important to many of us than gobbling up GPU resources to solve a problem that doesn't really appear to exist anywhere else. It's innovative, I'll grant them that, and maybe it'll prove to be a good design decision. I remain skeptical at this time.
We had the same problem in one of our buildings for a while - putting in Verizon-specific repeaters. Somehow, they interfere with other signal. Imagine that. The AT&T repeater never borked Verizon signal, but once you put in the Verizon repeater even the AT&T repeater wasn't enough to get signal.
Rip 'em out, replace 'em with a set of Wilson or other third-party non-carrier-specific repeater, Life Is Good.
You can't really compare the maps anyway.
Verizon's map is a coverage area map. They paint broad swaths of area where they have towers, but don't show any gaps in signal. Even up here in Verizon country (New England), I found that Verizon has plenty of dead zones where I don't get signal yet I'm in an area of the map that says I should. Verizon just takes each tower (I guess) and paints a circle around it with the theoretical diameter that the tower could reach.
AT&T's map, as far as I can see, is an actual signal map If I zoom in on it, I see predicted levels of signal and gaps in coverage that correspond roughly with the gaps I actually experience when I'm going places. It's not perfectly accurate, of course, but at least it makes the apparent attempt to be honest about actual signal. I don't know how they do it - perhaps they simply check terrain in Google Earth and look for landscape that "shadows" a tower. But whatever - I find it's very rare for me to lose signal in areas where the AT&T map shows coverage.
So, while Verizon may technically be accurate in stating that they have better "3G coverage" nationwide, I bet if you actually compared signal (that is, areas where you can actually get a 3G signal, and not areas within x miles of a tower regardless of terrain), Verizon's map would look a whole lot less thorough.
Verizon has the better 3G coverage. Fine, I get that. Of course, I don't have a 3G capable phone so I really don't care. But I get that it is important to some people. Verizon even has (marginally) better Voice/non-3G Data coverage here in New England.
But I had no way of honestly comparing them based on the coverage maps. AT&T showed me incomplete coverage that matched my real-world experience with my prepaid Go! phone. Verizon showed absolute 100% coverage everywhere which certainly did NOT match our experience with my wife's Verizon phone.
Example: My mother lives in a small town on the coast. When I go to her house, coverage is VERY spotty - you basically have to be near a window to get a bar or two. Verizon and AT&T have the exact same actual signal - very low (1-2 bars) and you have to pretty much be at a window standing still to make a call and have any hope of completing a conversation. My wife's Verizon phone and my AT&T phone were pretty much identical in performance.
The maps tell a very different story. AT&T shows my mother's house as "no coverage" along with a good chunk of the peninsula she lives on. Verizon shows the entire peninsula she lives on with full-on 3G coverage, no gaps whatsoever. Most of the peninsula has *no coverage of any kind* with AT&T or Verizon.
I finally concluded that I'd rather be told the truth, and when my company offered the choice of carriers for my Crackberry I went with AT&T. It didn't hurt, of course, that Verizon also locks out the GPS on the models we had, and AT&T allows me to use it (Verizon CLAIMED you could, but then they told you afterward that you had to buy the $10/month TeleNav service and even then you STILL wouldn't be allowed to use the GPS with anything other than TeleNav, Blackberry Maps, and Google Maps).
I have no particular love for AT&T, but at least they appear to be making an effort at honesty about their signal coverage, and when they sell me a phone with a feature installed they let me use the feature.
But please read the rest of the post.
"As a default, it doesn't".
If I manage 10 computers and need to install new software for everyone, I'll bop on down to their desks and install it at night, no biggie. I neither want nor need this turned on.
If I manage 10,000 computers, I'm never going to have the staff to do that. So I'm going to set up an internal repository and make approved applications available on it. Then my Linux image could have this feature turned on, along with a customized list of "approved signing authorities" which would be MY repository server (or servers - I might have one repo for finance apps and another for all users, for example).
If the company approves an application, I put it on the internal repo and tell users it's available if they want/need it.
And if an individual user needs something special, I can still use root to install it for them.
Yes, because as everyone knows, whenever ANYONE speaks about Linux, it's the SAME person who made another previous statement about Linux.
UAC is an excellent attempt at a Windows implementation a proper security model (temporary escalation of authority for a specific task, with prompting). Personally my only complaint about UAC was that it took Microsoft so long to finally come around to something like it. I run XP as a limited user, and it's very frustrating to see all the software that has been written for Windows that assumes you are running as Admin simply because that's the Windows XP default.
And, yes, I'm clearly and keenly aware that Microsoft is not responsible in any way for the laziness or incompetence of third party developers who write code that runs on their OS. But it does point back to the whole issue that's plagued Microsoft all along - security was ignored for way too long in Redmond, and continued as an oft-ignored afterthought well after they had gained a reputation for writing insecure code. I will give them credit - once they finally extracted cranium from anus and got the clue meter off zero, they made a relatively impressive turnaround in security in a very respectable amount of time.
It depends on your environment. For an individual user, you'd want sudo or su and you'd want to be prompted for each install. And that's a good thing.
But in a large corporate environment, I might want to make a bank of internal applications available (similar to Microsoft's "Run Advertised Programs"). I could configure all of my corporate desktops to only recognize the signing authority of a repository I own, then any of my users can install anything they want off that repository. But installs of things not on the "approved" list and therefore in the repository require root access.
However, this configuration setting was still a Bad Move on RedHat's part. If a corporation wants to allow this, they'll probably also want to think about the list of signing authorities they want to use. So this should be OFF by default and if an administrator wants to turn it ON they'd need to take action (and would presumably know what they are doing and why).
In a corporate environment, this does make sense.
As a default, it doesn't, because if you're a corporation wanting to extend this authority you'll almost certainly want to spend some time configuring the trusted authority list so you can host "approved" applications on an internal server.
Fortunately, this is a policy setting and not a code change. RedHat should change the default back to "requires root", though, because anyone who wants to change this policy should know what they are doing and make the appropriate configuration changes to control (or not) the applications that can be installed.
No, there is a significant difference between "running as Admin" and "installing a signed application without requiring root (Linux's Admin) authority".
The amount of authority granted depends on how many signing authorities you have decided to trust. If you trust only a server under your own control, for example, this could be really useful within an organization to allow users to install company-authorized packages without having to run around and install everything for everyone, while still preventing average users from doing anything to the machine.
I don't agree with this change in RedHat, but it is (fortunately) a policy change and not a programming change. In other words, it's easy for any machine owner to change the policy (which can, by the way, only be done as root) and require that all software installs be done by root only (which was the old default). In my opinion, this default should be changed back, and those people who want to send signed packages out within their organizations can change the policy.
A regular RedHat user still cannot do things like reformat the hard drive, change operating system files or core system configurations, access any data but their own, etc. Similar to a "Limited" user account in Windows (but the difference is that Microsoft, by default, has traditionally made all accounts Admin, and a lot of software vendors have come to depend on that so making a Limited user is an exercise in deep frustration in Windows).
Good points all.
2. could not agree more. Direct heating of water is the most efficient way to get, well, hot water. ;) In fact, such systems are becoming popular here in the Northeast. We don't have optimal sunlight, but at 16 cents a kwh, we sure have expensive enough electricity to justify using what little Sun we get to our advantage!
Off-grid is a decent use of solar. However, generation need not be at the household level, and storage need not be in the form of batteries.
An experiment was proposed here in Maine that was intriguing. A company wanted to dig a gigantic hole in the ground where the Maine Yankee nuclear plant used to be. That hole would be several hundred feet deep, adjacent to the ocean.
Interestingly enough it was designed to be, in essence, a battery.
When power was needed, let the hole fill up with seawater, and capture the energy as electricity to feed into the grid. When excess power was available, use it to pump water back out of the hole.
No battery technology to deal with - you're storing the power as potential energy. As long as you keep the hole empty, you have a pretty massive amount of potential energy that can be converted to electricity.
The beauty of that scheme would be for tidal power, where you have very predictable points in the cycle where you cannot generate power (slack tide) and predictable points where you generate WAY over average power (half-tide when water is really moving fast). So you use some of the power at half-tide to generate power to empty the hole, then at slack tide use that to generate power while the tide is turning around.
Could also be useful for wind power, though when the wind goes out you never know when it'll be back. Solar power could be a good supplemental source for this, though you'd have to have a very large hole to get through long cloudy periods around here.
For our area, tidal for electrics and solar for direct heat (house heating, hot water) would probably be our ideal mix, maybe with a little photosolar at the house level but connected to the grid. Perhaps with one of those holes in the ground here and there to get through the bad spots where we don't get a lot of Sun (we call them "Mud Season", most people call them "Spring").
6. Nuclear may be part of the discussion, pretty much anywhere, but now we get back to the whole point of this whole thread. The claim from CERN that we may have exceeded "Peak Nuke".
The elephant in the room in EVERY discussion about peak oil, climate change, alternative fuels, etc has basically been "if the anti-nuke groups would just get over their fear of nuclear power, we could dot the landscape with silos and everyone would get all the power they need." Fair enough, and with enough nuclear material we could.
Nuclear power has always been a panacea that, if we could just get over our fear of it, could bail our asses out of a shortage.
Except, now, according to CERN, it's not. We're already overdrawing that account by using up all our disposed nuclear weapons for fuel.
Now, that's a damned good use for old bombs if you ask pretty much anyone, but once we run out of them what do we do?
Net effect: Slight increases in development effort.
As I understand it, you can install additional functionality into Firefox in one of two ways:
1. Use the built-in installer. This is the "countdown box" that confirms that you want to install what the software is asking to install. It checks compatibility, and offers the capability of checking for updates and validating compatibility when a new version of Firefox gets installed (and disabling software that has NOT been tested with that specific flavor of Firefox).
2. Throw a file into a plugins or addons directory and Firefox will look for it and load it unconditionally next time it starts.
Sounds to me like they are going to reduce or eliminate #2.
So, as a developer, you'll probably have to package your plugins into a Firefox install package rather than an old Netscape-style plugin. You'll build that package specifying what versions of Firefox you have tested your plugin with, and the user will be informed that a new plugin wants to be installed.
Firefox could also fix this by scanning for all plugins and enumerating the ones that the user has identified as "safe", while prompting for any new ones that aren't in the database yet (or that have had their version numbers or file dates changed).
But that's more of a patch - the real solution is to protect the directory and only allow installs through the Firefox UI. I would be very curious to find out how they intend to protect the directory, though maybe they are simply ignoring anything "unexpected" that happens to be sitting there.
Possibly, but compare that to what we do now for electricity.
What's the thermal impact of a 100-acre solar plant as opposed to that of the portion of uncaptured soot generated by a coal fired power plant? And how much additional heat will be retained by the now-released CO2?
How does a rise in local air temperature compare to, say, raising the local water temperature along the shoreline to cool a nuclear plant?
No matter what we do to generate power, we are going to have an environmental impact. The most efficient way to "generate" power is to not use it, but there are practical limits to that.
So we need to generate power. Which source is least impactful and (very important) isn't going to run out on us?
Of course, if you made a solar array large enough that the heat creates a thermal and puts a permanent cloud over the array, I think you'd break a hole in the space/irony continuum. The problem would be self-correcting (shade cuts the heat allowing the cloud to dissipate) but you're getting a whole lot less power output during the dissipation phase.
It could lead to some interesting solutions, though - putting some sort of wind generator to capture some of the energy in the rising hot air and use that as well.
Actually, if we could come up with something like that, Washington DC could probably power most of the Eastern Seaboard.
I find it hard to watch movies like this one. I cannot suspend reality enough. Yet, I watch Star Trek where humanity has ended all internal conflict. Go figure.
and some of those holidays are only on certain classes of items, up to a certain amount, etc. Fun!
The first year Maine added Use Taxes, I decided to itemize. I had about $500 in receipts, give or take. It took me FOUR FREAKING HOURS to go through the receipts and figure out what tax rate applied to each item.
Now I just check the Alternative Minimum tickybox on my tax form, and to hell with it. My time's worth more than that.
But the point is that the Mayan calendar isn't even ending. The long view goes out past our year 4000...