IE is a better browser than it used to be, but it started out so far behind that they're going to be catching up for a while yet.
For example, their DOM selection range support is still way behind, as is their memory management. (It is absolutely unacceptable to tell JavaScript coders that they should not add methods to an element or they'll cause memory leaks. I mean, really!?!)
And IE still has fascinatingly severe bugs. For example, create a trivial HTML page that uses Javascript to set the src property of an existing iframe to the same URL as the loading page, and none of the JavaScript scripts on the second page ever run. (IE 9) The only robust workaround I've found is to replace the iframe with a new element. That workaround, in turn, when combined with IE's hack where they dispose of the DOM tree for an iframe's contents when the iframe is detached even if parts of it are still in use by JavaScript code (their hack "fix" for the aforementioned memory leaks) led to hours of extra debugging for me. (Wait, how can contentDocument.body legally be null?)
And it is fairly easy to wedge things using its development pane. And its contentEditable support is seriously subpar. (You can't easily select content that spans a div boundary, for example.) And it caches XHR requests when other browsers don't, which caused me lots of headaches (though admittedly I should have been sending appropriate headers to begin with).
Even in its current, much-improved state, IE is still a plague. If they keep up this level of improvement, it might be a viable browser for the website I'm developing in 5 years. As it is, I'm going to support Firefox, Safari, and Chrome, but I have no plans to support IE at this time. It just isn't feasible to work around all
the bugs—even in IE 9. We'll see about IE 10, but I'm not holding my breath.
I'd expect that much powder going off at once to cause hearing damage. I'd give it six months for the tinnitus lawsuits to start rolling in.
Ob. cartoon paraphrase: Where's the kaboom? There was supposed to be an ear-shattering kaboom. (Spoken by someone unaware that the blood running out of his ears came from what is left of his eardrums....)
Which would require multiple utility corridors all of which would need to be maintained, twice as many "unsightly" poles and twice the cost of running the service in the first place - read higher lot prices, twice the maintenance work to keep the trees cut back....
Not at all. Just build all the power infrastructure in loops. You have to run power lines down both parallel streets anyway. Just run an extra line every so often between the two streets and make sure you keep the wires the same length. Better still, use switching hardware so that you can detect a cable break on either side, automatically send a signal back to the home office that the line needs repair, and switch over to the other side.
The bigger problem is that the lines are overhead, causing the need for tree trimming in the first place. Every time a power line goes down because of trees, they should temporarily patch around the damage, but they should immediately send out the trenchers and begin running permanent replacement lines underground. There's simply no excuse for overhead power lines in areas where trees are present.
The betamax ruling was that time shifting was not copyright infringement.
And it is reasonable to argue that time shifting is still not copyright infringement even if it involves someone else's hardware doing the capturing for you, followed by transmitting it over the Internet. In any sane universe, copyright infringement can only occur if you aren't already paying for access to that content.
The uploader and the distributor, however, have no real defense because they do not verify that the downloader had a legal right to the content.
True, but the whole point of having a locked-down boot loader is to prevent malicious modification to everything, not just the kernel. This will eventually lead to kernel changes that require signed binaries. That will almost inevitably be an eventual requirement for being allowed to sign the kernel. A secure bootstrap loader and kernel don't mean anything if an attacker can exploit a couple of security holes, gain root privileges, and load crap into the kernel after the fact.
The GPL places no restrictions at all on use. It places restrictions on distribution.
That may be a moot point. If no one is allowed to distribute a version of the software compiled in such a way that will run on the hardware, no one can run it on the hardware. Whether that would be the case depends on how you interpret the GPL.
GPLv3 requires unlocked hardware, mandating that if the user is in not in charge, the user is not allowed to use the software. Another software company mandates that all hardware vendors require bootstrap loaders in order to be qualified to run their OS. Now, suddenly there's a whole host of hardware vendors that have to choose whether to take the safe bet and ship a Windows-based OS or completely and probably permanently sever their ties with Microsoft.
When it comes to stomping Linux into the ground, the GPLv3 is Microsoft's wet dream.
you could claim that it's rejecting right to tinker in a sandbox - which seems to be a goal, not an oversight
The problem is that more and more hardware is moving towards signed firmware. This transition is inevitable because the level of malware in computing today is just too high, and the only way to reliably prevent malware is to know with some degree of certainty who wrote a particular piece of code. Within 5-10 years, you will likely be unable to buy commodity hardware that can run unsigned code (except maybe for specialized server boxes). This is inevitable, and isn't something you can change by whining about it.
So your choices are pretty much either to accept that the world is changing and adapt or continue pissing into the wind. Either way, the result will be the same. If you want freedom to tinker, you're going to have to provide an alternative. This means either passing laws to mandate that vendors provide an alternative or coming up with a standard scheme for single-device-specific signing certificates (and shared infrastructure to provide such certificates) that the hardware vendors can all agree to support. Either way, there are several prerequisites:
All the Linux vendors must accept that code signing is inevitable.
All the Linux vendors must start moving towards adding code signing and verifying capabilities to the standard Linux distributions (assuming they aren't there already—I haven't looked in a while).
All the Linux vendors must work together to come up with shared infrastructure to support per-device signatures.
Anything short of that pretty much spells the end of Linux except as an embedded OS and/or specialized server OS on specialized hardware. Whether it happens now or ten years from now is unimportant. That's the direction things are going. Ubuntu et al took the first step in that list, but that step is incompatible with GPLv3 unless and until the remaining two steps are taken.
GPL3 on Grub works as designed here: it stops any DRM, disallowing unmodifiable bootloaders and kernels.
No, not really. As designed, it was intended to prevent hardware vendors from designing hardware with locked-down Linux installations. In this case, it is trying (unsuccessfully) to prevent enthusiasts from being able to install locked-down Linux on off-the-shelf ARM hardware without breaking their ability to switch back to Windows. The fact that you also won't be able to install non-locked-down Linux on that hardware is a secondary issue. It's a clear case of the GPLv3 acting against the right to tinker solely for reasons of ideological purity—the right to change everything or the right to change nothing.... That's truly backwards in my book.
The fact of the matter is that not enough people care about running Linux to convince manufacturers to push back on Microsoft over the ARM UEFI Secure Boot mandate. There is exactly one way to guarantee the right to tinker, and that is to get people from the geek community elected to governing bodies so that they can propose and pass legislation that mandates that right. Any other strategies are doomed to failure. It doesn't even have to be federal law. If the State of California passed a law saying that all electronic devices purchased using California tax dollars must provide a way for the user to install alternative operating systems without removing the user's ability to run the OS that came with it, Microsoft's attempts at mandating non-disableable UEFI Secure Boot on ARM would go down like a lead balloon even if no other legislature adopted such a provision.
Sounds like they're making the right decision, then. By moving to native code instead of doing most of their communication using XMLHttpRequest (presumably), they'll be in control over their caching behavior, which could make them better able to avoid being a memory pig. Also by using native code, they won't be running interpreted or JIT-compiled code, which means battery life should improve noticeably as well.
UI Rendering speed is exactly the same for native code and html elements. The reason is, guess what browsers do to show you lists, buttons, drop down boxes, etc?? They use *NATIVE* UI elements.
Although that is pedantically true if you did all your own UI drawing using programmatic calls and did all your own layout work using something as complicated as the DOM and CSS, in practice, you're completely and totally wrong. The UI layout engine used for a native app is orders of magnitude faster. And this is why UI latency is so much worse for web-based UIs.
HTML based UI cause increased round trips from mobile devices to their data-centers creates a terrible experience for users when compared to native apps.
No, not really. A native UI has to make the exact same requests to the server to get the exact same data. Bear in mind that Facebook's UI is not served by some PHP script returning a page full of data. The server provides a simple HTML page once when you open the app or browser, and everything else is done dynamically by making JSON requests for the raw data, followed by handing that off to JavaScript code that mutates the DOM. Thus, to the extent that the new version they're designing has better latency, the improvement is entirely caused by differences between the insane complexity of the DOM and the relative simplicity of a springs-and-struts layout model (or whatever).
HTML + CSS + JS is the worst "modern" paradigm to base any kind of UI on.
No disagreement there. Even with flex boxes, it is just barely starting to approach the level of flexibility that native UI controls have supported for a good two decades. A few weeks ago, it took me three days of CSS monkeying to design a moderately complex UI pane in CSS and HTML that would have taken two or three minutes in Interface Builder. Even simple things like "make this box the same height as that box, make them start X pixels from the top of the window and Y pixels from the bottom of the window, with the contents scrollable, and make the left box contain a series of tabs for the right box, with no right border for the selected tab, and if the contents don't fill the entire left box, fill the remaining area with a given color" turn out to be a royal pain in the backside with CSS because you make one change to fix one problem and it breaks something else.
HTML/CSS isn't modern at all. It's a pile of hacks on top of a pile of hacks on top of a pile of hacks. It is quite possibly the absolute worst way to design a user interface that any sane person could come up with. But it is the only portable choice when we're designing stuff on the web, and that's the reality you have to live with. That said, if you have to write a native app anyway to gain access to hardware features, you'd be crazy to then say, "I'm going to make my life miserable by designing 99% of the UI using HTML and CSS.":-)
In Facebook's case, the problem with WORA is much larger than that. Because the interpreter must be consistent across all environments, it is difficult to take maximum advantage of features that do not exist everywhere. Not just the sorts of device capabilities that impact HTML5, e.g. screen size, but also device features, e.g. address book, built-in camera, etc. that cannot be taken advantage of from within a web app.
As a result of this, the Facebook app was never WORA. It was a custom, probably iOS-specific, chimera of a web app and a native app that did some things with native code and other things with web code. This sort of design is inherently fragile, and there were a lot of bugs (of such severity that if you exited the app in certain views, you would be unable to launch Facebook until you deleted and redownloaded the app) that were almost certainly caused by the design.
More importantly, Facebook does pretty much everything with JSON and other similar services anyway (as opposed to providing static HTML content), so there is no real advantage to using HTML for the UI. It adds lots of complexity (two programming languages instead of one, plus the complex interface between them), reduces performance (even with JIT, JavaScript is likely to be a little slower than native code), and leaves you at the mercy of a browser engine for your UI instead of being able to code anything that the native widgets can support.
This year, my small credit union had to spend half a million dollars replacing perfectly good ATMs so that a headphone jack can be plugged into them.
ATMs are mostly Windows PCs under the hood, so they should have been able to add one by handing just about any random person a drill and a panel-mount audio jack pre-wired to an 1/8" mini plug on the other end.... Maybe with a Y cable for the internal speaker. Sounds to me more like your Credit Union was looking for an excuse to upgrade their crappy, old ATMs.:-)
At which point Netflix would then be obligated to refuse to provide those pieces of content until the creators provide the subtitles, at which point the creators would be forced to provide the subtitles. More to the point, these rules would apply to all similar services, presumably, so if the content providers don't solve the problem, they'll lose most of their digital distribution.
There is some flexibility allowed for providing content created prior to when the rules were adopted, so this doesn't require magically creating subtitles where none exist (unless they can't manage to strike a balance where at least 75% of their pre-rule content contains subtitles).
This doesn't suck at all. This is the law working exactly as it is supposed to work, doing exactly what it was intended to do. Now if we were talking about YouTube being forced to provide subtitles, that would be another matter....
What you're missing is that electronic synthesis is an incremental advancement relative to other computer technology and to some extent relative to audio recording technology, but it is not an incremental advancement relative to other musical instrument technology. It is an entirely different way of producing sound that pretty much spontaneously appeared in the past century out of nowhere.
For tens of thousands of years, musical instruments produced sounds because of a player striking something, plucking something, or blowing air over or through a tube (sometimes involving a reed or human lips simulating a reed) in some fashion. Each change was a small, incremental improvement in the way you do one of those things. The only thing that electronic synthesis has in common with previous musical instruments is that something vibrates (which is basically a fundamental requirement for creating sound).
We already know how to mostly prevent thyroid damage from radiation exposure. The thyroid is unique in that it uses large amounts of iodine in producing certain hormones. Unfortunately, many radioactive elements naturally break down into radioactive iodine (Iodine-131), and when the radioactive form is floating around your bloodstream, the thyroid dutifully absorbs it just as it would the non-radioactive version. That bioaccumulation of Iodine-131 in the thyroid is what causes such a high rate of thyroid cancer after radiation exposure. That's why the standard treatment for radiation exposure includes massive doses of normal iodine. By ensuring that most of the iodine that reaches the thyroid is not radioactive, the damage to the thyroid is dramatically reduced.
A piano really isn't a technological marvel and never was. Even at the time, it was seen as a fairly straightforward improvement upon the harpsichord and the clavichord, the main difference between a piano and the latter being that the piece that strikes the string does not remain in contact with it. The mechanism was a definite improvement, but it was very much an incremental improvement over existing technology, the fundamentals of which are merely a more modern version of the hammered dulcimer/santur, which dates back roughly the time when Christianity was founded, coupled with a keyboard that evolved (over the centuries) from the pipe organ/hydraulis, which dates back to roughly the 3rd century B.C.
In fact, until the last century, all modern musical instruments are fairly easy to trace back in concept to something that existed at or before the time of Christ. That's why electronic music is so shocking; it is really the first major revolutionary jump in music production in thousands of years. It makes previous major jumps (e.g. the first valved horn in the early 1800s) look almost microscopic by comparison. It is no surprise to see a fair number of people conclude that it is too new—too different.
No, hypocrisy means pretending to have virtues that you do not have. It is not hypocrisy to alter your beliefs over time.
You can't claim to follow a particular dogma and then pick and choose the bits of it you do believe as people whack-a-mole the fundamental tenets of that dogma.
Christianity is not "a particular dogma". It's thousands of wildly divergent belief systems that share exactly one thing in common: a belief in the teachings of Christ. At one extreme is Unitarianism—a Christian religion that recognizes Christ as a moral authority, but does not recognize Christ as divine. At the polar opposite end are the folks who believe the Earth was created 6,000 years ago, who consider every word of the Bible to be divine truth. Christianity is everything up to and including these two extremes.
That is based on a premise that there's no downside to that belief... But the last 2000 years is a long tattered history of reasons why those beliefs are a HUGE net negative to humanity.
No, there is no actual downside to religious belief. People don't start wars over religion. They start wars for several reasons: to gain power, wealth, or notoriety; for revenge; or to create buffer zones that isolate themselves from other cultures that they perceive as invasive. People use religion as an excuse. All of the downsides you're attributing to religion are, in fact, downsides attributable solely and completely to humans' lust for power, wealth, etc. In the absence of religious beliefs, there are a near-infinite number of other beliefs that can be abused and corrupted in much the same way to effectively the same ends, whether it's eugenics (WWII), racism (U.S. Civil War), or even the price of Tea (U.S. Revolutionary War). Those who want to stir up trouble are going to find a way to do so. We could go back in time and eradicate religious beliefs a millennia ago, and we'd still end up with horrible wars with lots of bloodshed.
The details will be different for everyone, but unless you're going to tell me everyone but me was using multiple Mb connections in the 1980's, I'm going to have to call bullshit on that claim. US access speeds have been steadily increasing every since I've been watching them, and they've continued to do so in the last few years. My connection went from 6 to 15 MB just a year or two ago.
How much did your bandwidth needs increase, though? The average size of a web page has increased by a factor of ten in the past decade, but my bandwidth has increased by only a factor of two. So my perceived access speeds have actually gone down by a factor of five over that time period. So did yours, by about a factor of two.
Ignorance is ignorance -- it doesn't matter if a larger number of people share it.
First, not all Christians are strict dogmatic believers in the things you think they are. We know with a reasonable degree of certainty that Jesus was an actual person. We know that he taught ideals of human behavior that are still good models for how people should treat one another. Any assumption that Christians believe something above and beyond those truths is something of a distortion of Christianity. A Christian is a follower of Christ's teachings, and need not be a follower of any teachings by anyone who came in the two thousand years since. Even people who do not believe in Christ's divinity can legitimately call themselves Christian if they live by his teachings. And arguably, those who do not live by his teachings are not Christian, regardless of what they believe.
Second, one of the core tenets of mainstream Christianity is belief in a higher power—a creator. There is nothing ignorant about that belief except insofar as belief by definition inherently reflects a lack of certainty. If I believe that a certain girl will agree to go out with me someday, that's not ignorant (at least until the fifth or sixth rejection, at which point it becomes stalking, but I digress). It is simply a belief in something that cannot be easily falsified. Even after decades, there's always some possibility that we'd meet again in a retirement home and fall in love. And by the time you can falsify it (one of the two people involved dies), the information is no longer meaningful. Amusingly, this is true for belief in a creator, too; we'll know for sure when we die (or we won't, depending), but by then, it is too late to do anything about it.
It is only when a belief leads to rejection of overwhelming evidence to the contrary that the belief becomes willful ignorance. If I believe that the law of gravity does not apply to Felis domesticus, that belief is willfully ignorant. Most Christians, statistically speaking, do not hold beliefs that fundamentally contradict science. Therefore, most Christians are not, as you put it, ignorant.
Slashdot Mirror
IE is a better browser than it used to be, but it started out so far behind that they're going to be catching up for a while yet.
For example, their DOM selection range support is still way behind, as is their memory management. (It is absolutely unacceptable to tell JavaScript coders that they should not add methods to an element or they'll cause memory leaks. I mean, really!?!)
And IE still has fascinatingly severe bugs. For example, create a trivial HTML page that uses Javascript to set the src property of an existing iframe to the same URL as the loading page, and none of the JavaScript scripts on the second page ever run. (IE 9) The only robust workaround I've found is to replace the iframe with a new element. That workaround, in turn, when combined with IE's hack where they dispose of the DOM tree for an iframe's contents when the iframe is detached even if parts of it are still in use by JavaScript code (their hack "fix" for the aforementioned memory leaks) led to hours of extra debugging for me. (Wait, how can contentDocument.body legally be null?)
And it is fairly easy to wedge things using its development pane. And its contentEditable support is seriously subpar. (You can't easily select content that spans a div boundary, for example.) And it caches XHR requests when other browsers don't, which caused me lots of headaches (though admittedly I should have been sending appropriate headers to begin with).
Even in its current, much-improved state, IE is still a plague. If they keep up this level of improvement, it might be a viable browser for the website I'm developing in 5 years. As it is, I'm going to support Firefox, Safari, and Chrome, but I have no plans to support IE at this time. It just isn't feasible to work around all the bugs—even in IE 9. We'll see about IE 10, but I'm not holding my breath.
That was kind of the joke....
I'd expect that much powder going off at once to cause hearing damage. I'd give it six months for the tinnitus lawsuits to start rolling in.
Ob. cartoon paraphrase: Where's the kaboom? There was supposed to be an ear-shattering kaboom. (Spoken by someone unaware that the blood running out of his ears came from what is left of his eardrums....)
Not at all. Just build all the power infrastructure in loops. You have to run power lines down both parallel streets anyway. Just run an extra line every so often between the two streets and make sure you keep the wires the same length. Better still, use switching hardware so that you can detect a cable break on either side, automatically send a signal back to the home office that the line needs repair, and switch over to the other side.
The bigger problem is that the lines are overhead, causing the need for tree trimming in the first place. Every time a power line goes down because of trees, they should temporarily patch around the damage, but they should immediately send out the trenchers and begin running permanent replacement lines underground. There's simply no excuse for overhead power lines in areas where trees are present.
And it is reasonable to argue that time shifting is still not copyright infringement even if it involves someone else's hardware doing the capturing for you, followed by transmitting it over the Internet. In any sane universe, copyright infringement can only occur if you aren't already paying for access to that content.
The uploader and the distributor, however, have no real defense because they do not verify that the downloader had a legal right to the content.
True, but the whole point of having a locked-down boot loader is to prevent malicious modification to everything, not just the kernel. This will eventually lead to kernel changes that require signed binaries. That will almost inevitably be an eventual requirement for being allowed to sign the kernel. A secure bootstrap loader and kernel don't mean anything if an attacker can exploit a couple of security holes, gain root privileges, and load crap into the kernel after the fact.
That may be a moot point. If no one is allowed to distribute a version of the software compiled in such a way that will run on the hardware, no one can run it on the hardware. Whether that would be the case depends on how you interpret the GPL.
GPLv3 requires unlocked hardware, mandating that if the user is in not in charge, the user is not allowed to use the software. Another software company mandates that all hardware vendors require bootstrap loaders in order to be qualified to run their OS. Now, suddenly there's a whole host of hardware vendors that have to choose whether to take the safe bet and ship a Windows-based OS or completely and probably permanently sever their ties with Microsoft.
When it comes to stomping Linux into the ground, the GPLv3 is Microsoft's wet dream.
The problem is that more and more hardware is moving towards signed firmware. This transition is inevitable because the level of malware in computing today is just too high, and the only way to reliably prevent malware is to know with some degree of certainty who wrote a particular piece of code. Within 5-10 years, you will likely be unable to buy commodity hardware that can run unsigned code (except maybe for specialized server boxes). This is inevitable, and isn't something you can change by whining about it.
So your choices are pretty much either to accept that the world is changing and adapt or continue pissing into the wind. Either way, the result will be the same. If you want freedom to tinker, you're going to have to provide an alternative. This means either passing laws to mandate that vendors provide an alternative or coming up with a standard scheme for single-device-specific signing certificates (and shared infrastructure to provide such certificates) that the hardware vendors can all agree to support. Either way, there are several prerequisites:
Anything short of that pretty much spells the end of Linux except as an embedded OS and/or specialized server OS on specialized hardware. Whether it happens now or ten years from now is unimportant. That's the direction things are going. Ubuntu et al took the first step in that list, but that step is incompatible with GPLv3 unless and until the remaining two steps are taken.
A web app UI framework that actually integrates with IB? Wow. I may have to play with that.
No, not really. As designed, it was intended to prevent hardware vendors from designing hardware with locked-down Linux installations. In this case, it is trying (unsuccessfully) to prevent enthusiasts from being able to install locked-down Linux on off-the-shelf ARM hardware without breaking their ability to switch back to Windows. The fact that you also won't be able to install non-locked-down Linux on that hardware is a secondary issue. It's a clear case of the GPLv3 acting against the right to tinker solely for reasons of ideological purity—the right to change everything or the right to change nothing.... That's truly backwards in my book.
The fact of the matter is that not enough people care about running Linux to convince manufacturers to push back on Microsoft over the ARM UEFI Secure Boot mandate. There is exactly one way to guarantee the right to tinker, and that is to get people from the geek community elected to governing bodies so that they can propose and pass legislation that mandates that right. Any other strategies are doomed to failure. It doesn't even have to be federal law. If the State of California passed a law saying that all electronic devices purchased using California tax dollars must provide a way for the user to install alternative operating systems without removing the user's ability to run the OS that came with it, Microsoft's attempts at mandating non-disableable UEFI Secure Boot on ARM would go down like a lead balloon even if no other legislature adopted such a provision.
Either way, it stops making sense after the next comma (splice). It should be a semicolon. And the comma after that one shouldn't be there at all.
Sincerely,
The Helpful Grammarian
Sounds like they're making the right decision, then. By moving to native code instead of doing most of their communication using XMLHttpRequest (presumably), they'll be in control over their caching behavior, which could make them better able to avoid being a memory pig. Also by using native code, they won't be running interpreted or JIT-compiled code, which means battery life should improve noticeably as well.
Although that is pedantically true if you did all your own UI drawing using programmatic calls and did all your own layout work using something as complicated as the DOM and CSS, in practice, you're completely and totally wrong. The UI layout engine used for a native app is orders of magnitude faster. And this is why UI latency is so much worse for web-based UIs.
No, not really. A native UI has to make the exact same requests to the server to get the exact same data. Bear in mind that Facebook's UI is not served by some PHP script returning a page full of data. The server provides a simple HTML page once when you open the app or browser, and everything else is done dynamically by making JSON requests for the raw data, followed by handing that off to JavaScript code that mutates the DOM. Thus, to the extent that the new version they're designing has better latency, the improvement is entirely caused by differences between the insane complexity of the DOM and the relative simplicity of a springs-and-struts layout model (or whatever).
No disagreement there. Even with flex boxes, it is just barely starting to approach the level of flexibility that native UI controls have supported for a good two decades. A few weeks ago, it took me three days of CSS monkeying to design a moderately complex UI pane in CSS and HTML that would have taken two or three minutes in Interface Builder. Even simple things like "make this box the same height as that box, make them start X pixels from the top of the window and Y pixels from the bottom of the window, with the contents scrollable, and make the left box contain a series of tabs for the right box, with no right border for the selected tab, and if the contents don't fill the entire left box, fill the remaining area with a given color" turn out to be a royal pain in the backside with CSS because you make one change to fix one problem and it breaks something else.
HTML/CSS isn't modern at all. It's a pile of hacks on top of a pile of hacks on top of a pile of hacks. It is quite possibly the absolute worst way to design a user interface that any sane person could come up with. But it is the only portable choice when we're designing stuff on the web, and that's the reality you have to live with. That said, if you have to write a native app anyway to gain access to hardware features, you'd be crazy to then say, "I'm going to make my life miserable by designing 99% of the UI using HTML and CSS." :-)
In Facebook's case, the problem with WORA is much larger than that. Because the interpreter must be consistent across all environments, it is difficult to take maximum advantage of features that do not exist everywhere. Not just the sorts of device capabilities that impact HTML5, e.g. screen size, but also device features, e.g. address book, built-in camera, etc. that cannot be taken advantage of from within a web app.
As a result of this, the Facebook app was never WORA. It was a custom, probably iOS-specific, chimera of a web app and a native app that did some things with native code and other things with web code. This sort of design is inherently fragile, and there were a lot of bugs (of such severity that if you exited the app in certain views, you would be unable to launch Facebook until you deleted and redownloaded the app) that were almost certainly caused by the design.
More importantly, Facebook does pretty much everything with JSON and other similar services anyway (as opposed to providing static HTML content), so there is no real advantage to using HTML for the UI. It adds lots of complexity (two programming languages instead of one, plus the complex interface between them), reduces performance (even with JIT, JavaScript is likely to be a little slower than native code), and leaves you at the mercy of a browser engine for your UI instead of being able to code anything that the native widgets can support.
Step 1: Manufacture a diamond-tipped rotary saw blade three meters thick and approximately one kilometer in radius.
Step 2: Purchase a used generator from a hydroelectric plant and wire it up as a motor.
Step 3: Purchase all the power from an active hydroelectric plant.
Step 4: Throw the switch and run like hell.
First one, then the other. :-D
ATMs are mostly Windows PCs under the hood, so they should have been able to add one by handing just about any random person a drill and a panel-mount audio jack pre-wired to an 1/8" mini plug on the other end.... Maybe with a Y cable for the internal speaker. Sounds to me more like your Credit Union was looking for an excuse to upgrade their crappy, old ATMs. :-)
Just saying.
At which point Netflix would then be obligated to refuse to provide those pieces of content until the creators provide the subtitles, at which point the creators would be forced to provide the subtitles. More to the point, these rules would apply to all similar services, presumably, so if the content providers don't solve the problem, they'll lose most of their digital distribution.
There is some flexibility allowed for providing content created prior to when the rules were adopted, so this doesn't require magically creating subtitles where none exist (unless they can't manage to strike a balance where at least 75% of their pre-rule content contains subtitles).
This doesn't suck at all. This is the law working exactly as it is supposed to work, doing exactly what it was intended to do. Now if we were talking about YouTube being forced to provide subtitles, that would be another matter....
What you're missing is that electronic synthesis is an incremental advancement relative to other computer technology and to some extent relative to audio recording technology, but it is not an incremental advancement relative to other musical instrument technology. It is an entirely different way of producing sound that pretty much spontaneously appeared in the past century out of nowhere.
For tens of thousands of years, musical instruments produced sounds because of a player striking something, plucking something, or blowing air over or through a tube (sometimes involving a reed or human lips simulating a reed) in some fashion. Each change was a small, incremental improvement in the way you do one of those things. The only thing that electronic synthesis has in common with previous musical instruments is that something vibrates (which is basically a fundamental requirement for creating sound).
We already know how to mostly prevent thyroid damage from radiation exposure. The thyroid is unique in that it uses large amounts of iodine in producing certain hormones. Unfortunately, many radioactive elements naturally break down into radioactive iodine (Iodine-131), and when the radioactive form is floating around your bloodstream, the thyroid dutifully absorbs it just as it would the non-radioactive version. That bioaccumulation of Iodine-131 in the thyroid is what causes such a high rate of thyroid cancer after radiation exposure. That's why the standard treatment for radiation exposure includes massive doses of normal iodine. By ensuring that most of the iodine that reaches the thyroid is not radioactive, the damage to the thyroid is dramatically reduced.
A piano really isn't a technological marvel and never was. Even at the time, it was seen as a fairly straightforward improvement upon the harpsichord and the clavichord, the main difference between a piano and the latter being that the piece that strikes the string does not remain in contact with it. The mechanism was a definite improvement, but it was very much an incremental improvement over existing technology, the fundamentals of which are merely a more modern version of the hammered dulcimer/santur, which dates back roughly the time when Christianity was founded, coupled with a keyboard that evolved (over the centuries) from the pipe organ/hydraulis, which dates back to roughly the 3rd century B.C.
In fact, until the last century, all modern musical instruments are fairly easy to trace back in concept to something that existed at or before the time of Christ. That's why electronic music is so shocking; it is really the first major revolutionary jump in music production in thousands of years. It makes previous major jumps (e.g. the first valved horn in the early 1800s) look almost microscopic by comparison. It is no surprise to see a fair number of people conclude that it is too new—too different.
No, hypocrisy means pretending to have virtues that you do not have. It is not hypocrisy to alter your beliefs over time.
Christianity is not "a particular dogma". It's thousands of wildly divergent belief systems that share exactly one thing in common: a belief in the teachings of Christ. At one extreme is Unitarianism—a Christian religion that recognizes Christ as a moral authority, but does not recognize Christ as divine. At the polar opposite end are the folks who believe the Earth was created 6,000 years ago, who consider every word of the Bible to be divine truth. Christianity is everything up to and including these two extremes.
No, there is no actual downside to religious belief. People don't start wars over religion. They start wars for several reasons: to gain power, wealth, or notoriety; for revenge; or to create buffer zones that isolate themselves from other cultures that they perceive as invasive. People use religion as an excuse. All of the downsides you're attributing to religion are, in fact, downsides attributable solely and completely to humans' lust for power, wealth, etc. In the absence of religious beliefs, there are a near-infinite number of other beliefs that can be abused and corrupted in much the same way to effectively the same ends, whether it's eugenics (WWII), racism (U.S. Civil War), or even the price of Tea (U.S. Revolutionary War). Those who want to stir up trouble are going to find a way to do so. We could go back in time and eradicate religious beliefs a millennia ago, and we'd still end up with horrible wars with lots of bloodshed.
How much did your bandwidth needs increase, though? The average size of a web page has increased by a factor of ten in the past decade, but my bandwidth has increased by only a factor of two. So my perceived access speeds have actually gone down by a factor of five over that time period. So did yours, by about a factor of two.
First, not all Christians are strict dogmatic believers in the things you think they are. We know with a reasonable degree of certainty that Jesus was an actual person. We know that he taught ideals of human behavior that are still good models for how people should treat one another. Any assumption that Christians believe something above and beyond those truths is something of a distortion of Christianity. A Christian is a follower of Christ's teachings, and need not be a follower of any teachings by anyone who came in the two thousand years since. Even people who do not believe in Christ's divinity can legitimately call themselves Christian if they live by his teachings. And arguably, those who do not live by his teachings are not Christian, regardless of what they believe.
Second, one of the core tenets of mainstream Christianity is belief in a higher power—a creator. There is nothing ignorant about that belief except insofar as belief by definition inherently reflects a lack of certainty. If I believe that a certain girl will agree to go out with me someday, that's not ignorant (at least until the fifth or sixth rejection, at which point it becomes stalking, but I digress). It is simply a belief in something that cannot be easily falsified. Even after decades, there's always some possibility that we'd meet again in a retirement home and fall in love. And by the time you can falsify it (one of the two people involved dies), the information is no longer meaningful. Amusingly, this is true for belief in a creator, too; we'll know for sure when we die (or we won't, depending), but by then, it is too late to do anything about it.
It is only when a belief leads to rejection of overwhelming evidence to the contrary that the belief becomes willful ignorance. If I believe that the law of gravity does not apply to Felis domesticus, that belief is willfully ignorant. Most Christians, statistically speaking, do not hold beliefs that fundamentally contradict science. Therefore, most Christians are not, as you put it, ignorant.
By my reading of the law, it is illegal to sell something to someone who you know intends to export it to Iran, so no, buying it is not always fine.