I am sorry, but I don't buy it... You have a theory how the world behaves. You do a numerical simulation based on that theory, and amazingly, it proves true. And you consider that a proof of your theory?
To turn it into a proof, you need to get the UN to claim that "every non-kook scientist in the world agrees that this is true, and every scientist who does not agree is a kook, or is being paid to disagree by a global corporate conspiracy that is trying to suppress this proof". Then you get the Nobel committee to give Al Gore a prize for making a movie about how true your simulation is.
Think of how the Polynesians colonized the entire Pacific in simple canoes.
Their canoes may have been fairly simple compared to modern ships, but they were the result of decades or centuries of development of sea-worthy craft. The Polynesians also had a very sophisticated system of navigation, with their own notion of GPS. Their navigators could tell, by looking at the stars, where they were and how to get from their to any of their islands.
I'm not saying their exploration and colonization wasn't brave; the Pacific ocean is a dangerous place in a large modern ship, let alone a canoe. But it's not like they just put out to sea and wandered blindly; they knew how to get to unexplored areas, and they knew how to get back to the closest land, and they could plan their explorations in a way that would keep them within reach of resupply at all times. It took a lifetime to train their navigators, so I doubt they would risk their lives by heading so far out that they'd have to find a new island or die.
What we need is a mandatory alarm on all vehicles that measures the distance to the car in front of you, determines how long it'll take to close that distance at your current speed, and sounds an alarm if it's less than 3 seconds. The alarm should be smart enough to be quiet when you're parking and braking, so it doesn't go off unnecessarily.
This would also be a good "Pay attention, you idiot" alarm for the people who are too busy on their cellphones to pay attention to the stopped/slow traffic in front of them on the highway. For the habitual tailgaters, it'll be even more annoying than the people they're tailgating and trying to get past.
No, the real issue was that Microsoft was requiring developers to write browser-specific code targeted specifically at IE8 in order to create pages that are not targeted at a specific browser. It doesn't take a degree to see the inherent contradiction here.
I think that depends on how you look at it. Take a look at these example headers:
X-UA-Compatible: IE=8
X-UA-Compatible: IE=8;FF=3;OtherUA=4
As a web-based application developer, what these headers say to me is that the page has been QA tested and certified using these particular browser vendors and versions, and that these are the browser vendors and versions that are explicitly supported. Presumably, since there are reasonably standards-compliant browsers in the list, any standards-compliant browser should be ok, but these are the ones that are certified to be ok on our web application.
If browsers like IE8 are smart enough to see this header, notice that an earlier version of itself is listed, and change its behavior to match that earlier version, that's great. It means that my company doesn't have to tie our release schedule to the unpredictable browser upgrades of our users. We can specify IE7 as the latest certified and supported version, and once IE8 starts to become popular we can add it to our testing roundup for the next release, where we will switch the header to IE8.
That's an accurate description of Capital Gains taxes, but the discussion is about Property taxes. Maybe you don't pay property taxes where you live, but in many US states every year you have to pay a percentage of the assessed value of property you own as a tax. For example, in the NJ town where I live, I currently pay 16% of the assessed value of my home and land. (66% of that goes to the local school board, 20% goes to the county, and 14% goes to my town.) Property values are just being reassessed now after 25 years; with the new assessment, the tax rate will probably drop to 2.5% to 3%.
So, every year I pay 3% of the approximate value of my property, whether I sell it or not. No mansion for me; even if it was given to me for free, I couldn't afford to own it.
Nice idea, but first you have to have enough to go around. This problem (as would many others) be solved with FEWER people shitting the place up.
That's real nice. "Hmm, this village lacks clean water; they're drinking out of the river and getting sick." "Oh, no problem, just shoot them all. They'll stop getting sick."
The way I see it, the only problem with the carbon we burn is that we're taking it out of the ground instead of out of the air.
Why take it out of the air, where it's feeding plants and supporting the entire ecosystem, rather than taking it out of the ground where it's not doing anyone any good? Do you want to starve the plants instead of fertilize them?
If you don't like taking it out of the ground, then how about let's take it out of our garbage. With today's oil prices ($100/barrel) it's economical to turn organic waste (farm refuse, but all kinds of plastic too) into oil. The last time I looked into the process, it cost about $50/barrel + the cost of getting the waste to the plant.
The security we have now isn't as good as public opinion makes it out to be; dogs couldn't be much worse. Also, terrorists may not be afraid of setting off a metal detector, or getting pulled out of line for manual inspection and possible detention, but they'd probably be more wary of the risk of being attacked by a pack of police dogs. Remember, any terrorist who's going to hijack a plane has been convinced that suffering a near instantaneous death is worthwhile; convincing that person to suffer through getting ripped to shreds by an animal is much tougher.
As far as the honest people who are afraid of either dogs or flying; I don't want them on my plane anyway.
Nowhere in the constitution does it provide a "right" to privacy, but not only was such a right "interpreted" to exist when no such right existed before, it brought with it the "right" to an abortion with strong arguments that this right is absolute (no exceptions).
You've got that backwards. The 10th Amendment, http://www.usconstitution.net/xconst_Am10.html, affirms that all rights which aren't discussed elsewhere in the Constitution belong to the people. The Constitution is a list of the rights and powers of the government, giving the government a limited authority over the natural rights of the people. It is not a list of the people's rights granted by the government.
In other countries, particularly in the Far East, changing the color of a device is sufficient to side-step a patent. Here in the US, patents aren't quite so specific, so you're right: a company making a device that implements all of the claims but uses a different codec would probably wind up in court.
However, if the particular codec isn't a crucial aspect of the invention, why does the claim specifically say MPEG? Most of the claims are fairly vaguely worded so that they'd cover alternative implementations, but this one is explicit about the codec. One could argue that a device using another codec must differ in a significant way.
My guess is that there is some licensing deal which requires TiVo to use MPEG and nothing else, and that's why they had to be explicit about it. It may also be that their implementation of the other claims, like the ring buffer, might be closely tied to the specifics of MPEG encoding, such that implementing those claims with a different encoding would require a completely different invention.
I've got a Dish Network DVR, and also a MythTV server. I've got MythTV hooked up to my cable internet hookup, where I'm able to pick up OTA analog channels and some unencrypted cable channels, but I can't hook into the Dish feed. If Dish is forced to discontinue their DVR, I'm going to push on them to supply me with a device that will let me use MythTV as a DVR. I'd be happy with a tuner card in my server that accepts the encoder card, or an external device that can be controlled using something other than an IR transmitter.
So if I want to make a new browser, I have to not only write it to display pages properly, but I now have to write it to display pages the same way as all the old versions of IE?
Only if your new browser happens to be a new version of IE, and for some reason you can't just use the existing implementations (DLLs) of the old versions of IE
I'm sick of having to implement different pages for different browser. The IE 8 proposal only exacerbates this problem to the extreme. Yes, it'll be very easy to add a "it works in ie8" tag...except that you need to support SEVERAL browsers, at least firefox and safari. You'll need to implement another TWO implementations of your page...or let firefox/safari to use the ie7 mode.
Today, I have standards-compliant pages that Firefox handles just fine (maybe the latest Safari release does too, if they've fixed long-standing javascript bugs which have prevented my company from officially supporting them) and I have conditional comments and some CSS traps which Firefox ignores but IE6 and IE7 use to tweak the rendering for them. When IE8 is first released, I'll have exactly the same thing, with a header that ensures IE8 behaves exactly like IE7. After my QA department spends some time testing IE8 in it's standards-compliant mode, I'll change the header, and IE8 will start rendering the pages like Firefox does, ignoring the conditional comments and CSS traps. The only thing I need to change is the conditional comments, to make them say "IE6 and IE7" instead of "IE >= 6".
The point is, why should you have to do any of this crap in the first place? You should not do any extra work to make compliant pages render correctly in a broken browser.
If you just enjoy yelling at the windmills, have fun. Me, I've got a job to do, and I need to deal with the reality that 40% of my users have IE7, 30% have IE6, and only 15% have Firefox. My users don't care what my browser preference is, but my bosses sure do care about how my application looks in the browsers my users are using.
Eleven years and running, almost as long as the tubes have had webpages running through them. Do I still count as new if I'm not crusty yet?
Not only will you have to test your page with browsers running in virtual machines, over the course of time you'll have to test it in IE8 pretending to be IE7, IE8 pretending to be IE6, IE9 pretending to be IE8, IE9 pretending to be IE7, and so on as you change the tag to benefit from newer rendering modes. All those render modes will either use combined code, which means they won't render exactly as the old versions, or they are essentially multiple browsers in one, which means they'll each have their own security vulnerabilities and plugin incompatibilities.
Seriously, you're not a software engineer, are you? The way the Microsoft engineers will almost certainly do this is by continuing to ship the MSIE rendering engine used by IE7 as a DLL file in IE8. Sure, that'll have all of the failings that IE7 currently does, but that's the point: the page will be rendered by IE7, exactly the same way it does today, because it's the same code doing the rendering. You do know that 'Internet Explorer' is just a thin wrapper around the rendering engine/library, and that the engine is used by many other applications as well, right? (Come to think of it, they probably won't have to ship the DLL with IE8, because it'll already be on everyone's system to support the non-IE applications that depend on it.)
If another browser sees that made-for-IE7 tag, it must recreate all of IE7's quirks (and those of IE6 and IE8 and IE9...)
What are you smoking? Why would other browsers do anything differently than they do today? We're talking largely about standards-compliant pages that have IE-specific tweaks that are triggered by IE6 and IE7 specific bugs, and making sure that when IE8 is released it won't get tripped up by those tweaks... if the page explicitly says "I'm for IE7", then IE8 will act like IE7 and display the tweaks like IE7 would. If the page says "I'm for IE8", then IE8 will act like a standards-compliant browser, and render the page normally (assuming the page author has altered things like conditional comments so that they only apply to IE6 and IE7). If the page doesn't say which way to go, I think the plan is for IE8 to act like IE7, to avoid breaking pages in the common case which is that most pages today are designed to render ok in IE7.
No, actually you'll be adding a tag that says "This page displays properly on IE7, Firefox 2, and some other browsers I tested it with" and it'll be up to the browser to figure out how to be compliant with you. In IE's case, IE8 will see that and say "I'd better render this page like IE7 does, because it probably has IE-specific workarounds that'll render incorrectly in IE8's really-standard-compliant rendering."
When you're good and ready, and you see enough IE8 hits in your access log to make it worthwhile, you can get IE8, test your pages, and if they look good, you can update the tag. It'll be under your control when users start to see the new rendering engine in IE8; you won't have to worry about when your users decide to upgrade themselves.
This approach has some great benefits; the IE team actually can safely break compatibility with IE6 and IE7 specific websites and implement standards correctly, because those websites will continue to be rendered with the existing renderer until they explicitly say it's safe to render with IE8's renderer. If they do this well, all we web developers will need to do is remove any IE-specific workarounds if the browser is not IE6/7... IE8 will be treated like any other standards-compliant browser, with no special coding or styling.
Another great benefit for us developers is that we'll be able to change the new tag to get an IE7 rendering from IE8... no more virtual machines just to have different versions of IE on the system. (Except for IE6, but Microsoft is supposedly going to try to force most IE6 users to IE7 next month.)
I can't tell you how much time I've wasted over the past few years trying to get standards compliant pages to look right in IE6 and IE7. I'll be very happy to be able to have my Apache server insert a response header that says "This page is for IE7; deal with it" and not have to worry that my application is going to break when people start to upgrade to IE8 in-between my releases.
I have rails/nginx sites that see over 100,000 people a day without any difficulty. They're clustered over four servers, none of which peaks at more than a half of its capacity. Five years ago I was running similarly busy sites under mod_perl and apache 1.3.x. The architecture was more powerful but less robust. I could do much all sorts of interesting things with the apache lifecycle - rails feels like lego by comparison - but the whole assembly was flaky and temperamental, each mod_perl process took up to 50MB and I lived in constant fear of the whole thing falling over.
For my company I've developed a large and complex web application that handles over 4 million requests per day, spread over about a dozen servers. It's pure Perl, with a custom HTTP/1.1 server written in Perl, and an Apache server in front of it serving static files and proxying dynamic requests back to the Perl server.
I wouldn't worry too much; another poster posted a quote that the sea level is rising 0.2mm/year. At that rate, your tallest hill has 850 thousand years before it'll go under.
Two scenarios are more likely: one is that Denmark will become more temperate, with less brutal winters. The other is that the Gulf Stream will be interrupted, there won't be any more warn water sent up into the northern Atlantic, and Denmark will become the southern end of a new glacier/ice cap.
Perl is a victim of its own success. It's very easy to use for quick-and-dirty tools, and as a result it is very commonly used by non-programmers (eg: sysadmins) who do not follow good software development methodologies. The IT world is full of unmaintainable Perl code, just like it is full of unmaintainable shell code. This isn't the language's fault; if Perl didn't exist, there would be more shell code, and probably a shell language that is as capable as Perl.
There's plenty of unmaintainable code written in other languages, too. The only difference is a lower volume because other highly-capable languages are difficult enough to use that only programmers use them. Make those languages easier to use, and you'll get non-programmers using them and creating unmaintainable code. They need to use something, so they're not just going to go away, no matter how difficult you make things for them, or how much you try to get professional programmers to do all of the programming work.
A professional programmer, who is trained in the way I suggest, can produce very maintainable code in Perl or any other language. The difference that I've found (being a professional programmer) is that Perl lets me be much more productive than other languages do, because I don't need to specify as much of the behavior that I want. I can do my coding at a higher and more abstract level, and the compiler figures out the appropriate behavior. It's similar to the difference in abstraction between assembly and C, except at a higher level.
A language like Java helps the programmer in some ways, but it's not enough. For example, Java sort of frees you from worrying about memory allocation, compared to C or C++, but you still have to worry about creating and destroying objects. Sure, it's a higher level of abstraction, but it's the same problem and it's still dumped in the programmer's lap. Similarly, when you define a type in Java you're creating a class with Integers and Strings as data members rather than worrying about 16-bit vs 32-bit vs 64-bit ints and whether the memory allocated for strings is static or dynamic, null-terminated or not, etc. However, you're still all hung up in specifying and tracking datatypes, and manually converting between them when necessary.
You're talking about fission and radioactive decay, which stops at lead. Basically, as I remember it, many of the elements which are heavier than lead decay by spitting off clumps of neutrons and protons until they become a lead isotope, and then they stop.
Helium atoms are composed of two protons and one or two neutrons. (Other numbers of neutrons are possible, but unstable.) Radioactive elements won't decay all the way down to a helium atom, but helium atoms are sometimes spit off as the decay product; that's where helium comes from on Earth. It's a slow process though, so it's not a viable source for large quantities.
The other way to make helium is by assembling it from individual protons and neutrons; this is fusion. This is what the sun does constantly: it puts hydrogen atoms (single protons) under intense pressure which causes the protons to bind together, forming a helium atom and a burst of energy. If we ever get fusion working as a power source, it'll generate helium as a by-product, and we'll have plenty of the stuff around.
Perl can be used as a functional language. It can also be used as an object-oriented language, especially if you use a modern OO library instead of the low-level core support for object-oriented development. Perl is also a great structured programing language too, of course.
Other than Systems Programming and Operating Systems, you could use Perl and CPAN to address all of the computer science subjects you mention, and you could use the Inline module and the other modules in its namespace to teach other languages, within the context of a Perl development framework.
I'm not suggesting that universities should switch from all-Java to all-Perl (though doing so would probably improve productivity for most programmers, so long as they're taught to use Best Practices and not create the write-only code that bad/non programmers often create with Perl.) Instead, I'm thinking that an introductory course could teach Perl syntax and best practices, and use that as a basis to provide introductory training in all of the different development styles and subjects you've touched upon. By using one language that is flexible enough to cover this wide variety of material, the topics could be covered without confusing beginning students with a variety of languages.
Of course you don't have to carry ID around with you in the UK; they can identify you using the cameras and face/gait recognition software everywhere you go.
I guess if you're going to live in a surveillance society, it's better to have the surveillance open and explicit than hidden away where you're not aware of it.
I cruise every year, and I'm happy they have these cards. The best thing about them, from a passenger's point of view, is that the cruise ship knows exactly who has left the ship, whether or not everyone has gotten back on-board at the end of the day, and whether or not anyone who doesn't belong has tried to get on-board. They always say that you need to get back on-board on time because the ship will leave without you if you don't, but I suspect that they wait. More than once my ship has stayed in port beyond the scheduled time, and I've seen stragglers come running up the pier. In the Carribean where I cruise, most of the ports are only a few hours apart and the ship sails all night, so it's easy to make up lost time spent waiting for late passengers.
The cards really don't slow anything down either; there's a queue to get everyone over the narrow gangplank anyway, and a quick optical scan of the barcode on the card while you pass the counter is all that is needed. Coming back on-board, the bigger hassle is the metal detector and x-ray you and your stuff (respectively) have to go through, but even that is much quicker than at an airport. (The TSA could really learn a thing or two from cruise lines... on the ship, you're not even standing and waiting in line, you're just reduced to a slow walk as you go through the inspection.)
Side Note: if you go on an official excursion and you're running late, the excursion operators let the ship know where you are, and the ship knows who you are. If you go off by yourself and you're running late returning, the ship knows you're not back yet but they don't know where you are. Always carry the port information packet with you; it contains the contact number for the ship in that port, so you can call them and let them know you're on your way back. If they know you're coming, they may wait for you.
I guess I'm an optimist. I do agree that both the public and the government would resist the idea at first, but I'm hopeful that these mini-reactors will someday become commonplace as municipal power generation systems. Once every small city and large town has one, which will only happen if they're proven to be safe, then they might start being deployed on ships.
I live in a town which has one of the highest per-capita property taxes in the country: services are expensive in this area, and we have too few homes and nearly no businesses for the tax base. One of my ideas for fixing the situation would be to lease one of these new reactors. My understanding is that only a small locked-down facility would be needed, and it would generate far more power than my town would need, so we could sell the excess to the power company and use the profits from that to cover the lease and pay for most/all of the town's budget.
...we don't want every merchant ship in the world to have a nuclear reactor on board, for obvious reasons.
Those reasons are...? You can't just throw a potential solution away and say that the reasons for rejection are obvious, without saying what they are.
I'll give you a start: it's probably too expensive right now. However, that'll change as diesel gets more scarce and expensive, and it will change as nuclear power, and the industry around it, gets more efficient. (Remember, there was a time when steam and oil engines were rarely used because they were more expensive and problematic than their predecessors.)
I don't think we'll ever see full-scale nuclear reactors of the type we have on naval ships in cargo and passenger ships. You need too many highly-trained crew members to maintain the things, and they probably generate far more power than cargo and passenger ships need. I also don't think we'll see current RTG technology on ships; a hunk of radioactive material might generate enough heat to generate electricity for a satellite, but it's not going to be able to move a ship.
What I do think we might someday see on ships is the new breed of miniature self-contained nuclear reactors that are currently under development. These things are small enough to fit on a railroad car or tractor trailer, supposedly need little or no maintenance, and can generate enough power for a few thousand / tens of thousands of homes. That should be enough to drive a big ship at 20-30 knots and provide electrical power for the whole ship.
I assumed that each module element has it's own receive hooks (one on each side of the connection) so that if you have multiple modules, they won't interfere with each other. I didn't think there would be a global receive hook, but I didn't read the details of his suggestion; maybe that is what he's proposing. If so, then I agree with you, that's a lousy paradigm.
In fact, I agree with you anyway. If you're doing a mashup, you might have multiple modules that have been designed to be hooked together, which could lead to a situation where you have two listeners for the same receive hook. You don't want to have to set up a page-level event distribution receive hook to coordinate this; you want to let module A add itself as a listener to module B's receive hook. I haven't looked at HTML5 in detail yet either, but this does sound like a solved problem.
Slashdot Mirror
To turn it into a proof, you need to get the UN to claim that "every non-kook scientist in the world agrees that this is true, and every scientist who does not agree is a kook, or is being paid to disagree by a global corporate conspiracy that is trying to suppress this proof". Then you get the Nobel committee to give Al Gore a prize for making a movie about how true your simulation is.
Their canoes may have been fairly simple compared to modern ships, but they were the result of decades or centuries of development of sea-worthy craft. The Polynesians also had a very sophisticated system of navigation, with their own notion of GPS. Their navigators could tell, by looking at the stars, where they were and how to get from their to any of their islands.
I'm not saying their exploration and colonization wasn't brave; the Pacific ocean is a dangerous place in a large modern ship, let alone a canoe. But it's not like they just put out to sea and wandered blindly; they knew how to get to unexplored areas, and they knew how to get back to the closest land, and they could plan their explorations in a way that would keep them within reach of resupply at all times. It took a lifetime to train their navigators, so I doubt they would risk their lives by heading so far out that they'd have to find a new island or die.
What we need is a mandatory alarm on all vehicles that measures the distance to the car in front of you, determines how long it'll take to close that distance at your current speed, and sounds an alarm if it's less than 3 seconds. The alarm should be smart enough to be quiet when you're parking and braking, so it doesn't go off unnecessarily.
This would also be a good "Pay attention, you idiot" alarm for the people who are too busy on their cellphones to pay attention to the stopped/slow traffic in front of them on the highway. For the habitual tailgaters, it'll be even more annoying than the people they're tailgating and trying to get past.
I think that depends on how you look at it. Take a look at these example headers:
- X-UA-Compatible: IE=8
- X-UA-Compatible: IE=8;FF=3;OtherUA=4
As a web-based application developer, what these headers say to me is that the page has been QA tested and certified using these particular browser vendors and versions, and that these are the browser vendors and versions that are explicitly supported. Presumably, since there are reasonably standards-compliant browsers in the list, any standards-compliant browser should be ok, but these are the ones that are certified to be ok on our web application.If browsers like IE8 are smart enough to see this header, notice that an earlier version of itself is listed, and change its behavior to match that earlier version, that's great. It means that my company doesn't have to tie our release schedule to the unpredictable browser upgrades of our users. We can specify IE7 as the latest certified and supported version, and once IE8 starts to become popular we can add it to our testing roundup for the next release, where we will switch the header to IE8.
That's an accurate description of Capital Gains taxes, but the discussion is about Property taxes. Maybe you don't pay property taxes where you live, but in many US states every year you have to pay a percentage of the assessed value of property you own as a tax. For example, in the NJ town where I live, I currently pay 16% of the assessed value of my home and land. (66% of that goes to the local school board, 20% goes to the county, and 14% goes to my town.) Property values are just being reassessed now after 25 years; with the new assessment, the tax rate will probably drop to 2.5% to 3%.
So, every year I pay 3% of the approximate value of my property, whether I sell it or not. No mansion for me; even if it was given to me for free, I couldn't afford to own it.
That's real nice. "Hmm, this village lacks clean water; they're drinking out of the river and getting sick." "Oh, no problem, just shoot them all. They'll stop getting sick."
Why take it out of the air, where it's feeding plants and supporting the entire ecosystem, rather than taking it out of the ground where it's not doing anyone any good? Do you want to starve the plants instead of fertilize them?
If you don't like taking it out of the ground, then how about let's take it out of our garbage. With today's oil prices ($100/barrel) it's economical to turn organic waste (farm refuse, but all kinds of plastic too) into oil. The last time I looked into the process, it cost about $50/barrel + the cost of getting the waste to the plant.
The security we have now isn't as good as public opinion makes it out to be; dogs couldn't be much worse. Also, terrorists may not be afraid of setting off a metal detector, or getting pulled out of line for manual inspection and possible detention, but they'd probably be more wary of the risk of being attacked by a pack of police dogs. Remember, any terrorist who's going to hijack a plane has been convinced that suffering a near instantaneous death is worthwhile; convincing that person to suffer through getting ripped to shreds by an animal is much tougher.
As far as the honest people who are afraid of either dogs or flying; I don't want them on my plane anyway.
You've got that backwards. The 10th Amendment, http://www.usconstitution.net/xconst_Am10.html, affirms that all rights which aren't discussed elsewhere in the Constitution belong to the people. The Constitution is a list of the rights and powers of the government, giving the government a limited authority over the natural rights of the people. It is not a list of the people's rights granted by the government.
In other countries, particularly in the Far East, changing the color of a device is sufficient to side-step a patent. Here in the US, patents aren't quite so specific, so you're right: a company making a device that implements all of the claims but uses a different codec would probably wind up in court.
However, if the particular codec isn't a crucial aspect of the invention, why does the claim specifically say MPEG? Most of the claims are fairly vaguely worded so that they'd cover alternative implementations, but this one is explicit about the codec. One could argue that a device using another codec must differ in a significant way.
My guess is that there is some licensing deal which requires TiVo to use MPEG and nothing else, and that's why they had to be explicit about it. It may also be that their implementation of the other claims, like the ring buffer, might be closely tied to the specifics of MPEG encoding, such that implementing those claims with a different encoding would require a completely different invention.
I've got a Dish Network DVR, and also a MythTV server. I've got MythTV hooked up to my cable internet hookup, where I'm able to pick up OTA analog channels and some unencrypted cable channels, but I can't hook into the Dish feed. If Dish is forced to discontinue their DVR, I'm going to push on them to supply me with a device that will let me use MythTV as a DVR. I'd be happy with a tuner card in my server that accepts the encoder card, or an external device that can be controlled using something other than an IR transmitter.
Only if your new browser happens to be a new version of IE, and for some reason you can't just use the existing implementations (DLLs) of the old versions of IE
In other words, no.
Today, I have standards-compliant pages that Firefox handles just fine (maybe the latest Safari release does too, if they've fixed long-standing javascript bugs which have prevented my company from officially supporting them) and I have conditional comments and some CSS traps which Firefox ignores but IE6 and IE7 use to tweak the rendering for them. When IE8 is first released, I'll have exactly the same thing, with a header that ensures IE8 behaves exactly like IE7. After my QA department spends some time testing IE8 in it's standards-compliant mode, I'll change the header, and IE8 will start rendering the pages like Firefox does, ignoring the conditional comments and CSS traps. The only thing I need to change is the conditional comments, to make them say "IE6 and IE7" instead of "IE >= 6".
If you just enjoy yelling at the windmills, have fun. Me, I've got a job to do, and I need to deal with the reality that 40% of my users have IE7, 30% have IE6, and only 15% have Firefox. My users don't care what my browser preference is, but my bosses sure do care about how my application looks in the browsers my users are using.
Eleven years and running, almost as long as the tubes have had webpages running through them. Do I still count as new if I'm not crusty yet?
Seriously, you're not a software engineer, are you? The way the Microsoft engineers will almost certainly do this is by continuing to ship the MSIE rendering engine used by IE7 as a DLL file in IE8. Sure, that'll have all of the failings that IE7 currently does, but that's the point: the page will be rendered by IE7, exactly the same way it does today, because it's the same code doing the rendering. You do know that 'Internet Explorer' is just a thin wrapper around the rendering engine/library, and that the engine is used by many other applications as well, right? (Come to think of it, they probably won't have to ship the DLL with IE8, because it'll already be on everyone's system to support the non-IE applications that depend on it.)
What are you smoking? Why would other browsers do anything differently than they do today? We're talking largely about standards-compliant pages that have IE-specific tweaks that are triggered by IE6 and IE7 specific bugs, and making sure that when IE8 is released it won't get tripped up by those tweaks... if the page explicitly says "I'm for IE7", then IE8 will act like IE7 and display the tweaks like IE7 would. If the page says "I'm for IE8", then IE8 will act like a standards-compliant browser, and render the page normally (assuming the page author has altered things like conditional comments so that they only apply to IE6 and IE7). If the page doesn't say which way to go, I think the plan is for IE8 to act like IE7, to avoid breaking pages in the common case which is that most pages today are designed to render ok in IE7.
No, actually you'll be adding a tag that says "This page displays properly on IE7, Firefox 2, and some other browsers I tested it with" and it'll be up to the browser to figure out how to be compliant with you. In IE's case, IE8 will see that and say "I'd better render this page like IE7 does, because it probably has IE-specific workarounds that'll render incorrectly in IE8's really-standard-compliant rendering."
When you're good and ready, and you see enough IE8 hits in your access log to make it worthwhile, you can get IE8, test your pages, and if they look good, you can update the tag. It'll be under your control when users start to see the new rendering engine in IE8; you won't have to worry about when your users decide to upgrade themselves.
This approach has some great benefits; the IE team actually can safely break compatibility with IE6 and IE7 specific websites and implement standards correctly, because those websites will continue to be rendered with the existing renderer until they explicitly say it's safe to render with IE8's renderer. If they do this well, all we web developers will need to do is remove any IE-specific workarounds if the browser is not IE6/7... IE8 will be treated like any other standards-compliant browser, with no special coding or styling.
Another great benefit for us developers is that we'll be able to change the new tag to get an IE7 rendering from IE8... no more virtual machines just to have different versions of IE on the system. (Except for IE6, but Microsoft is supposedly going to try to force most IE6 users to IE7 next month.)
I can't tell you how much time I've wasted over the past few years trying to get standards compliant pages to look right in IE6 and IE7. I'll be very happy to be able to have my Apache server insert a response header that says "This page is for IE7; deal with it" and not have to worry that my application is going to break when people start to upgrade to IE8 in-between my releases.
I wouldn't worry too much; another poster posted a quote that the sea level is rising 0.2mm/year. At that rate, your tallest hill has 850 thousand years before it'll go under.
Two scenarios are more likely: one is that Denmark will become more temperate, with less brutal winters. The other is that the Gulf Stream will be interrupted, there won't be any more warn water sent up into the northern Atlantic, and Denmark will become the southern end of a new glacier/ice cap.
Either way, you'll keep your head above water.
Perl is a victim of its own success. It's very easy to use for quick-and-dirty tools, and as a result it is very commonly used by non-programmers (eg: sysadmins) who do not follow good software development methodologies. The IT world is full of unmaintainable Perl code, just like it is full of unmaintainable shell code. This isn't the language's fault; if Perl didn't exist, there would be more shell code, and probably a shell language that is as capable as Perl.
There's plenty of unmaintainable code written in other languages, too. The only difference is a lower volume because other highly-capable languages are difficult enough to use that only programmers use them. Make those languages easier to use, and you'll get non-programmers using them and creating unmaintainable code. They need to use something, so they're not just going to go away, no matter how difficult you make things for them, or how much you try to get professional programmers to do all of the programming work.
A professional programmer, who is trained in the way I suggest, can produce very maintainable code in Perl or any other language. The difference that I've found (being a professional programmer) is that Perl lets me be much more productive than other languages do, because I don't need to specify as much of the behavior that I want. I can do my coding at a higher and more abstract level, and the compiler figures out the appropriate behavior. It's similar to the difference in abstraction between assembly and C, except at a higher level.
A language like Java helps the programmer in some ways, but it's not enough. For example, Java sort of frees you from worrying about memory allocation, compared to C or C++, but you still have to worry about creating and destroying objects. Sure, it's a higher level of abstraction, but it's the same problem and it's still dumped in the programmer's lap. Similarly, when you define a type in Java you're creating a class with Integers and Strings as data members rather than worrying about 16-bit vs 32-bit vs 64-bit ints and whether the memory allocated for strings is static or dynamic, null-terminated or not, etc. However, you're still all hung up in specifying and tracking datatypes, and manually converting between them when necessary.
You're talking about fission and radioactive decay, which stops at lead. Basically, as I remember it, many of the elements which are heavier than lead decay by spitting off clumps of neutrons and protons until they become a lead isotope, and then they stop.
Helium atoms are composed of two protons and one or two neutrons. (Other numbers of neutrons are possible, but unstable.) Radioactive elements won't decay all the way down to a helium atom, but helium atoms are sometimes spit off as the decay product; that's where helium comes from on Earth. It's a slow process though, so it's not a viable source for large quantities.
The other way to make helium is by assembling it from individual protons and neutrons; this is fusion. This is what the sun does constantly: it puts hydrogen atoms (single protons) under intense pressure which causes the protons to bind together, forming a helium atom and a burst of energy. If we ever get fusion working as a power source, it'll generate helium as a by-product, and we'll have plenty of the stuff around.
Perl can be used as a functional language. It can also be used as an object-oriented language, especially if you use a modern OO library instead of the low-level core support for object-oriented development. Perl is also a great structured programing language too, of course.
Other than Systems Programming and Operating Systems, you could use Perl and CPAN to address all of the computer science subjects you mention, and you could use the Inline module and the other modules in its namespace to teach other languages, within the context of a Perl development framework.
I'm not suggesting that universities should switch from all-Java to all-Perl (though doing so would probably improve productivity for most programmers, so long as they're taught to use Best Practices and not create the write-only code that bad/non programmers often create with Perl.) Instead, I'm thinking that an introductory course could teach Perl syntax and best practices, and use that as a basis to provide introductory training in all of the different development styles and subjects you've touched upon. By using one language that is flexible enough to cover this wide variety of material, the topics could be covered without confusing beginning students with a variety of languages.
Of course you don't have to carry ID around with you in the UK; they can identify you using the cameras and face/gait recognition software everywhere you go.
I guess if you're going to live in a surveillance society, it's better to have the surveillance open and explicit than hidden away where you're not aware of it.
I cruise every year, and I'm happy they have these cards. The best thing about them, from a passenger's point of view, is that the cruise ship knows exactly who has left the ship, whether or not everyone has gotten back on-board at the end of the day, and whether or not anyone who doesn't belong has tried to get on-board. They always say that you need to get back on-board on time because the ship will leave without you if you don't, but I suspect that they wait. More than once my ship has stayed in port beyond the scheduled time, and I've seen stragglers come running up the pier. In the Carribean where I cruise, most of the ports are only a few hours apart and the ship sails all night, so it's easy to make up lost time spent waiting for late passengers.
The cards really don't slow anything down either; there's a queue to get everyone over the narrow gangplank anyway, and a quick optical scan of the barcode on the card while you pass the counter is all that is needed. Coming back on-board, the bigger hassle is the metal detector and x-ray you and your stuff (respectively) have to go through, but even that is much quicker than at an airport. (The TSA could really learn a thing or two from cruise lines... on the ship, you're not even standing and waiting in line, you're just reduced to a slow walk as you go through the inspection.)
Side Note: if you go on an official excursion and you're running late, the excursion operators let the ship know where you are, and the ship knows who you are. If you go off by yourself and you're running late returning, the ship knows you're not back yet but they don't know where you are. Always carry the port information packet with you; it contains the contact number for the ship in that port, so you can call them and let them know you're on your way back. If they know you're coming, they may wait for you.
I guess I'm an optimist. I do agree that both the public and the government would resist the idea at first, but I'm hopeful that these mini-reactors will someday become commonplace as municipal power generation systems. Once every small city and large town has one, which will only happen if they're proven to be safe, then they might start being deployed on ships.
I live in a town which has one of the highest per-capita property taxes in the country: services are expensive in this area, and we have too few homes and nearly no businesses for the tax base. One of my ideas for fixing the situation would be to lease one of these new reactors. My understanding is that only a small locked-down facility would be needed, and it would generate far more power than my town would need, so we could sell the excess to the power company and use the profits from that to cover the lease and pay for most/all of the town's budget.
Those reasons are...? You can't just throw a potential solution away and say that the reasons for rejection are obvious, without saying what they are.
I'll give you a start: it's probably too expensive right now. However, that'll change as diesel gets more scarce and expensive, and it will change as nuclear power, and the industry around it, gets more efficient. (Remember, there was a time when steam and oil engines were rarely used because they were more expensive and problematic than their predecessors.)
I don't think we'll ever see full-scale nuclear reactors of the type we have on naval ships in cargo and passenger ships. You need too many highly-trained crew members to maintain the things, and they probably generate far more power than cargo and passenger ships need. I also don't think we'll see current RTG technology on ships; a hunk of radioactive material might generate enough heat to generate electricity for a satellite, but it's not going to be able to move a ship.
What I do think we might someday see on ships is the new breed of miniature self-contained nuclear reactors that are currently under development. These things are small enough to fit on a railroad car or tractor trailer, supposedly need little or no maintenance, and can generate enough power for a few thousand / tens of thousands of homes. That should be enough to drive a big ship at 20-30 knots and provide electrical power for the whole ship.
I assumed that each module element has it's own receive hooks (one on each side of the connection) so that if you have multiple modules, they won't interfere with each other. I didn't think there would be a global receive hook, but I didn't read the details of his suggestion; maybe that is what he's proposing. If so, then I agree with you, that's a lousy paradigm.
In fact, I agree with you anyway. If you're doing a mashup, you might have multiple modules that have been designed to be hooked together, which could lead to a situation where you have two listeners for the same receive hook. You don't want to have to set up a page-level event distribution receive hook to coordinate this; you want to let module A add itself as a listener to module B's receive hook. I haven't looked at HTML5 in detail yet either, but this does sound like a solved problem.