Since you listed the update as "critical", you need to balance the pros and cons of doing this type of update. While updating the OS is a requirement against vulnerabilities, updating a BIOS isn't like that(most of the time). Sometime, you just need to tell the boss, "listen, if we don't update the firmware, it's possible that we'll get that bug that will destroy our data, and if we update the firmware, it's possible that we'll get some other problem, I suggest "this" and "this" but you need to be aware of the risks."
For BIOS and firmware, generally the update isn't critical no matter what a manufacturer says, especially on equipment that's been running for years. I would't update any server hardware firmware after a year in service unless I was experiencing problems, as those servers will generally not see any operations that are not already happening - IOW, their purpose is set and they are operating fine as is. No change needed. I might monitor them more closely after such a bulletin though, and perhaps plan an earlier than expected replacement.
Then again, I see the forced obsolescence ending in a couple of years, at most. The next round of phones sound like they will all max out on noticeable screen and camera resolution for the form factor and useable CPU capabilities and bandwidth for the next 10 years. What comes next will be additional features, haptic touch screens, speciality communication additions such as real NFC / BT integration perhaps? And after that, it will have to be yet another devices functionality brought in. Maybe TV projectors, or the ever elusive tri-corder of ST fame.
Huh? When do you ever have to reboot a smartphone? I think I had to reboot my last two phones twice, total not each. Which, to me is a problem, since the only time you need to reboot is when your carrier decides to update, and carriers hate updates.
Guess that's one reason they all left Android.... Something about their phone being completely out of date and unsupported 3-6 months into a 24 month contract. Then again, if you like hacking your phone, that won't bother you. I'd rather just use my phone.
And apparently,from skimming the referenced articles, it appears that the server end has issues....
Wow, this iOS upgrade is so bad it's even affecting the servers!?
I would actually read that as Exchange is so bad that a typo can take it down. To each their own. We don't even know what the actual bug is, but the server should never go down from a message. It is ALWAYS up to the server to validate and handle inbound traffic appropriately. Never trust a client. Then again, this is MS we're talking about.
Well written. I came from other feature and almost smart phones to the iPhone. My Android friends have all switched to the iPhone over the past 3 years. They all profess to "love" their Android phone, and "miss" some feature. Yet none say they'll go back to an Android phone. Perhaps the almost never rebooting bit? The very good battery life? Some other feature? I personally miss the 7 day battery life from my previous phones. But I did get more features that I use a lot. And apparently I like them enough to go buy another one, as I'm about to do my upgrade.
... If you implement the protocol badly, it doesn't matter whether it's proprietary or not. If you don't control both ends of a connection, then you are entirely dependent on how the other end implement the protocol, proprietary or not.
And apparently,from skimming the referenced articles, it appears that the server end has issues....
Allowing (x) to happen does several things:
1. Signals social approval of (x)
That is, unfortunately, a fundamental fallacy that our society has embraced.
"moral" and "legal" are not synonyms and should not be treated as synonyms. They are separate concepts. Something may be moral and legal, moral and illegal, immoral and legal, or immoral and illegal. If more people understood that the culture war wouldn't be so bloody and we would have a much freer society.
Unfortunately, you're applying rational thought to an inherently irrational data set. The people that wish to control other people's actions care little for a free society, nor are their areas of control really rational, no matter what they say. The reason they're bloody is that those that wish to control must be defeated, no more or less than the Mongol horde had to be, for people to live free.
Pickup trucks are perfectly legal; does that make them government-recommended?
Decisions that affect the health of a society are different from the type of mundane shopping decision you're arguing. Do you really think drug use is on par with what type of car you drive?
I absolutely do. Perhaps I don't approve of caffeine use. You don't use caffeine, do you? The horror! What about aspirin? Nasal sprays? Antibiotic soaps? Pesticides around your house? All chemical / drug uses that have significant effects on society and the environment around you. What? You don't agree? Shocker!
I think you're confused here as well. The point of a free society is that you're not compelled to do things against your values. That doesn't mean there are no rules or standards. If anything, you've shown why our society has become "un-free" with the adoption of forced pluralism.
The only confused person here is you. You are confused that your desires, even if it seems reasonable to you, and you feel should be universal, are not considered reasonable by us to be imposed upon others, even if we have no desire to do said activity ourselves. The only actions we agree should be restricted are some of those wherein actions harm others other than the actor. For examples where this is not done currently are the practices of piercing babies ears, or circumcision.
You need a lot more than that to properly block facebook and company. What you're really wanting is a whitelist proxy. I'm about to add one to my network for other reasons.
It seems like you've made a political decision here, which is that every behavior should be accepted.
Not everyone agrees.
Some of us want our kids to grow up in a world where only healthy behaviors exist.
And here we have a perfect example of someone willing to impose their viewpoints on others while bristling at the thought of others exposing him to things he thinks are "bad". What a hypocritical control freak that doesn't have a clue what he's proposing.
You are entirely incorrect - it's a ripper, this isn't firmware, there is no content producer that supports this software.
BD+ has been broken for years. All versions. The entire approach was flawed from day one. The best thing the content folks could do is actually provide us with working product, instead of all this hackery that drives more and more folks to exercise their fair use rights and right of first sale. DMCA can actually be argued is in violation of the constitution, as it oversteps the boundaries allotted for Copyright. Copyright explicitly relates to the right to distribute copies, not the actual copying itself - something the **AA's routinely ignore in their paid for legislation.
I don't know - last time I actually had any insight into this, it was a very worrisome topic for the brass, at least for the US. So much so they banned working USB ports on all computers, among other things.
I guess you don't know how this works. Governments really really really do not want foreign spyware on their systems. I mean REALLY don't. To the extent that they'll track you down and throw you into Guantanamo don't, at least in the US case.
It all depends, if there's 1 thread assigned per context, then no. Nothing has to change, there is no context switching for a thread in general terms that thread management is concerned about. The JS Engine doesn't even need big changes in this scenario, and maybe none at all, as it already has at least some context set for handling multiple threads (See above Ajax discussion). The only thing we'd be doing is having the browser specify when a new context is created, and create and tie a new thread to that context for JS execution.
Explain how that scenario has different requirements from the current implementation in browsers, from the thread POV. I see none, other than the thread will only see JS for a single page and its children, which is what would happen if you only opened 1 top level window in your browser.
Correct, but you were saying that the JS engine itself should have a pool of threads, and that is what I was addressing.
Correct - that is what I'm saying, and I explain that on the whole, the only thing that changes is how the JS engine changes would be minimal from a page standpoint to support it. I'm not advocating multi-thread support within a page. But the underlying engine having thread management and being able to handle multiple pages, each in their own context, concurrently. That's a different beast, and your other points are below:
Going further - the I/O for cookies is handled underneath the JS engine, the JS engine itself, at least as far as page rendering and UI interaction goes, is single threaded.
Cookies were merely an example. There are plenty of cases where you need not only re-entrant functions, but thread-safe ones as well. Furthermore, even if the cookie I/O isn't handled by the JS engine itself, it's still irrelevant. If two pages are running (with one JS engine thread per page) and both try to access cookies, you really should hope the cookie accessors are thread-safe. Whether or not the access is done directly from the JS engine doesn't matter much as long as there are multiple threads running simultaneously.
You're missing the point - the JS engine code is single-threaded on a per page context, and contexts have no ability to speak or share with each other. Therefore there is no issue of thread safety in JS code. The discussion of underlying frameworks called by or on behalf of the JS engine is irrelevant. Those issues exist already, so there is 0 change. I'll bet the same is true for any scenario you'd care to post, since the core assumption, page contexts are single threaded, is unchanged.
as far as the JS engine goes, there is no IPC, and even in Chrome
I never claimed that there was IPC specifically in Chrome's JS engine. The point was that, as Chrome uses multiple processes, there is lots of IPC. Specifically, I was pointing out that for someone to add multi-processing to any given browser (in this case Firefox), even just for the JS engine, they'd need to do lots of work to get the IPC working. The only reason Chrome's JS engine doesn't do IPC is because it is part of the same processes as the renderer AFAIK.
See above, IPC is not relevant, thanks to the unchanged assumption about the scope of the change we're talking about. There will be some changes in the core JS Engine, and perhaps some synchronization imposed on calls the JS engine makes that are not there now, but that is all below the waterline, so to speak. No one's tackled this, and Chrome's approach is probably a least effort call. As for any IPC in Chrome, it's irrelevant to this discussion about the JS Engine as that IPC will exist in either configuration and is beneath the JS Engine.
Groundbreaking? Room temp super conductors. Hi-strength material suitable for space elevator. Understanding the genome (cures cancer etc). Optical computing. Quantum computing. Warp drive. Unified Theory. Anti-gravity. Energy-mass convertors. Anti-matter power sources. Transporters.
One or more of those will happen sooner than later, and may be done by an individual somewhere, although several not likely due to scope of equipment. But, you never know. Any of those should provide a large shift in how we live. However, I wonder if quantum computing will really wind up being groundbreaking or not. We all know what the theory is, but we have yet to see working proof. Out of all those listed, it seems the most likely and imminent, but also possibly having the least impact.
You are entirely wrong on China - they copy and make things cheaper. Usually with a major reduction in quality. There was a saying - Chinese steel is good for one use. I have a toolset (gift), a couple of screwdrivers and a utility knife from a local hardware store, and a couple of other items that prove that saying. I avoid anything steel from China, even flatware. Their steel quality is so bad that even 18-0 stainless steel sports and even rusts, due to the lack of quality of the alloy. Hint, throwing together ingots in proper ratios, melting and stirring once does not high quality steel make, but it's certainly cheaper.
To your question of why we can't do the same: namely, our workers can't live on $10 / week, and we can't compete with a country that controls its internal economy so that it feeds free market economies while preventing their result locally (ie, US companies would buy up all food etc in China until the price went up, if China didn't restrict that type of activity) You need to look far beyond what you're considering for the real reason of China's "success". The answer is a GAT, applied at the border, on everything. It also will fix another local problem, while raising prices of goods from artificially cheap places like China.
At the risk of tl;dr, the initial sets of paras are more about backend browser threading than IPC. IPC is a whole different ball of wax from mere threading. Nothing there states anything about how the JS engine is run.
Generally, JS is single-threaded, especially within a page. You'll note there's no "thread" type, class, nor anything else you can access from within the browser (to stay on topic, Node.js etc are not in scope) You can achieve multi-threading via Ajax, which does run a separate I/O and "thread" in JS, and can cause some interesting behavior (race conditions) if you have multiple Ajax calls affecting the same element set. Going further - the I/O for cookies is handled underneath the JS engine, the JS engine itself, at least as far as page rendering and UI interaction goes, is single threaded. That's important, because that's the entire problem mentioned several posts ago. If you want to state "but wait, I know I can set the download threads to 'x'" that's true, and that's the JS engine handing off URL requests to the underlying network I/O stack, which is where the multithreading resides. The JS Engine merrily continues its processing until it has either 1) finished processing everything in the current stack and is waiting on I/O to return, or 2) it has run out of network I/O threads to pass requests to. (Simplistic, I know, again, far too much to write otherwise) Essentially that's how it works under the covers. So even in Chrome, which I haven't tested this hypothesis, the network I/O could be limited by a single network I/O process if they're sharing... via IPC. Again, that would be under the covers and not at a JS engine level.
I have had more fun than I can relate here about digging through various JS frameworks to debug web 2.0 issues in various browsers. Chrome's 1 process per page is a nice simple way to achieve separation so that 1 page cannot affect another, which is a browser sandbox design anyways. Only parent/child pages should be able to talk to one another, and IIRC in Chrome, those run in the same process.
To summarize - as far as the JS engine goes, there is no IPC, and even in Chrome, the JS engine is single-threaded for rendering/UI interaction and still subject to locking. It's just 1 page that's affected instead of everything in the browser.
Slashdot Mirror
Since you listed the update as "critical", you need to balance the pros and cons of doing this type of update. While updating the OS is a requirement against vulnerabilities, updating a BIOS isn't like that(most of the time). Sometime, you just need to tell the boss, "listen, if we don't update the firmware, it's possible that we'll get that bug that will destroy our data, and if we update the firmware, it's possible that we'll get some other problem, I suggest "this" and "this" but you need to be aware of the risks."
For BIOS and firmware, generally the update isn't critical no matter what a manufacturer says, especially on equipment that's been running for years. I would't update any server hardware firmware after a year in service unless I was experiencing problems, as those servers will generally not see any operations that are not already happening - IOW, their purpose is set and they are operating fine as is. No change needed. I might monitor them more closely after such a bulletin though, and perhaps plan an earlier than expected replacement.
Then again, I see the forced obsolescence ending in a couple of years, at most. The next round of phones sound like they will all max out on noticeable screen and camera resolution for the form factor and useable CPU capabilities and bandwidth for the next 10 years. What comes next will be additional features, haptic touch screens, speciality communication additions such as real NFC / BT integration perhaps? And after that, it will have to be yet another devices functionality brought in. Maybe TV projectors, or the ever elusive tri-corder of ST fame.
Huh? When do you ever have to reboot a smartphone? I think I had to reboot my last two phones twice, total not each. Which, to me is a problem, since the only time you need to reboot is when your carrier decides to update, and carriers hate updates.
Guess that's one reason they all left Android.... Something about their phone being completely out of date and unsupported 3-6 months into a 24 month contract. Then again, if you like hacking your phone, that won't bother you. I'd rather just use my phone.
I guess it was too early/late for my humor level....
And apparently,from skimming the referenced articles, it appears that the server end has issues....
Wow, this iOS upgrade is so bad it's even affecting the servers!?
I would actually read that as Exchange is so bad that a typo can take it down. To each their own. We don't even know what the actual bug is, but the server should never go down from a message. It is ALWAYS up to the server to validate and handle inbound traffic appropriately. Never trust a client. Then again, this is MS we're talking about.
Well written. I came from other feature and almost smart phones to the iPhone. My Android friends have all switched to the iPhone over the past 3 years. They all profess to "love" their Android phone, and "miss" some feature. Yet none say they'll go back to an Android phone. Perhaps the almost never rebooting bit? The very good battery life? Some other feature? I personally miss the 7 day battery life from my previous phones. But I did get more features that I use a lot. And apparently I like them enough to go buy another one, as I'm about to do my upgrade.
... If you implement the protocol badly, it doesn't matter whether it's proprietary or not. If you don't control both ends of a connection, then you are entirely dependent on how the other end implement the protocol, proprietary or not.
And apparently,from skimming the referenced articles, it appears that the server end has issues....
Because it's not arbitrary. Some things work better than others. A society of obese people is going to have health problems.
So now you're going to argue that obese people are outlaws? Next up will be people that have views they wish to force other people to follow.
Default settings will result in a reboot by definition.
Allowing (x) to happen does several things: 1. Signals social approval of (x)
That is, unfortunately, a fundamental fallacy that our society has embraced. "moral" and "legal" are not synonyms and should not be treated as synonyms. They are separate concepts. Something may be moral and legal, moral and illegal, immoral and legal, or immoral and illegal. If more people understood that the culture war wouldn't be so bloody and we would have a much freer society.
Unfortunately, you're applying rational thought to an inherently irrational data set. The people that wish to control other people's actions care little for a free society, nor are their areas of control really rational, no matter what they say. The reason they're bloody is that those that wish to control must be defeated, no more or less than the Mongol horde had to be, for people to live free.
Now this is getting silly:
Decisions that affect the health of a society are different from the type of mundane shopping decision you're arguing. Do you really think drug use is on par with what type of car you drive?
I absolutely do. Perhaps I don't approve of caffeine use. You don't use caffeine, do you? The horror! What about aspirin? Nasal sprays? Antibiotic soaps? Pesticides around your house? All chemical / drug uses that have significant effects on society and the environment around you. What? You don't agree? Shocker!
I think you're confused here as well. The point of a free society is that you're not compelled to do things against your values. That doesn't mean there are no rules or standards. If anything, you've shown why our society has become "un-free" with the adoption of forced pluralism.
The only confused person here is you. You are confused that your desires, even if it seems reasonable to you, and you feel should be universal, are not considered reasonable by us to be imposed upon others, even if we have no desire to do said activity ourselves. The only actions we agree should be restricted are some of those wherein actions harm others other than the actor. For examples where this is not done currently are the practices of piercing babies ears, or circumcision.
Yep, then again, for my specific purposes, those sites aren't on the whitelist anyways, at least not for a while.
You need a lot more than that to properly block facebook and company. What you're really wanting is a whitelist proxy. I'm about to add one to my network for other reasons.
It seems like you've made a political decision here, which is that every behavior should be accepted.
Not everyone agrees.
Some of us want our kids to grow up in a world where only healthy behaviors exist.
And here we have a perfect example of someone willing to impose their viewpoints on others while bristling at the thought of others exposing him to things he thinks are "bad". What a hypocritical control freak that doesn't have a clue what he's proposing.
You are entirely incorrect - it's a ripper, this isn't firmware, there is no content producer that supports this software.
BD+ has been broken for years. All versions. The entire approach was flawed from day one. The best thing the content folks could do is actually provide us with working product, instead of all this hackery that drives more and more folks to exercise their fair use rights and right of first sale. DMCA can actually be argued is in violation of the constitution, as it oversteps the boundaries allotted for Copyright. Copyright explicitly relates to the right to distribute copies, not the actual copying itself - something the **AA's routinely ignore in their paid for legislation.
I don't know - last time I actually had any insight into this, it was a very worrisome topic for the brass, at least for the US. So much so they banned working USB ports on all computers, among other things.
I guess you don't know how this works. Governments really really really do not want foreign spyware on their systems. I mean REALLY don't. To the extent that they'll track you down and throw you into Guantanamo don't, at least in the US case.
Funny enough, I'm pretty sure my BD ripper program doesn't phone anybody, especially as it's not on the net.
Since they copied it directly from previous works, and it is a term currently in use in various places, can they actually trademark it? Just curious.
It all depends, if there's 1 thread assigned per context, then no. Nothing has to change, there is no context switching for a thread in general terms that thread management is concerned about. The JS Engine doesn't even need big changes in this scenario, and maybe none at all, as it already has at least some context set for handling multiple threads (See above Ajax discussion). The only thing we'd be doing is having the browser specify when a new context is created, and create and tie a new thread to that context for JS execution.
Explain how that scenario has different requirements from the current implementation in browsers, from the thread POV. I see none, other than the thread will only see JS for a single page and its children, which is what would happen if you only opened 1 top level window in your browser.
Correct, but you were saying that the JS engine itself should have a pool of threads, and that is what I was addressing.
Correct - that is what I'm saying, and I explain that on the whole, the only thing that changes is how the JS engine changes would be minimal from a page standpoint to support it. I'm not advocating multi-thread support within a page. But the underlying engine having thread management and being able to handle multiple pages, each in their own context, concurrently. That's a different beast, and your other points are below:
Going further - the I/O for cookies is handled underneath the JS engine, the JS engine itself, at least as far as page rendering and UI interaction goes, is single threaded.
Cookies were merely an example. There are plenty of cases where you need not only re-entrant functions, but thread-safe ones as well. Furthermore, even if the cookie I/O isn't handled by the JS engine itself, it's still irrelevant. If two pages are running (with one JS engine thread per page) and both try to access cookies, you really should hope the cookie accessors are thread-safe. Whether or not the access is done directly from the JS engine doesn't matter much as long as there are multiple threads running simultaneously.
You're missing the point - the JS engine code is single-threaded on a per page context, and contexts have no ability to speak or share with each other. Therefore there is no issue of thread safety in JS code. The discussion of underlying frameworks called by or on behalf of the JS engine is irrelevant. Those issues exist already, so there is 0 change. I'll bet the same is true for any scenario you'd care to post, since the core assumption, page contexts are single threaded, is unchanged.
as far as the JS engine goes, there is no IPC, and even in Chrome
I never claimed that there was IPC specifically in Chrome's JS engine. The point was that, as Chrome uses multiple processes, there is lots of IPC. Specifically, I was pointing out that for someone to add multi-processing to any given browser (in this case Firefox), even just for the JS engine, they'd need to do lots of work to get the IPC working. The only reason Chrome's JS engine doesn't do IPC is because it is part of the same processes as the renderer AFAIK.
See above, IPC is not relevant, thanks to the unchanged assumption about the scope of the change we're talking about. There will be some changes in the core JS Engine, and perhaps some synchronization imposed on calls the JS engine makes that are not there now, but that is all below the waterline, so to speak. No one's tackled this, and Chrome's approach is probably a least effort call. As for any IPC in Chrome, it's irrelevant to this discussion about the JS Engine as that IPC will exist in either configuration and is beneath the JS Engine.
And we'd finally have... the Jetsons!
Groundbreaking? Room temp super conductors. Hi-strength material suitable for space elevator. Understanding the genome (cures cancer etc). Optical computing. Quantum computing. Warp drive. Unified Theory. Anti-gravity. Energy-mass convertors. Anti-matter power sources. Transporters.
One or more of those will happen sooner than later, and may be done by an individual somewhere, although several not likely due to scope of equipment. But, you never know. Any of those should provide a large shift in how we live. However, I wonder if quantum computing will really wind up being groundbreaking or not. We all know what the theory is, but we have yet to see working proof. Out of all those listed, it seems the most likely and imminent, but also possibly having the least impact.
You are entirely wrong on China - they copy and make things cheaper. Usually with a major reduction in quality. There was a saying - Chinese steel is good for one use. I have a toolset (gift), a couple of screwdrivers and a utility knife from a local hardware store, and a couple of other items that prove that saying. I avoid anything steel from China, even flatware. Their steel quality is so bad that even 18-0 stainless steel sports and even rusts, due to the lack of quality of the alloy. Hint, throwing together ingots in proper ratios, melting and stirring once does not high quality steel make, but it's certainly cheaper.
To your question of why we can't do the same: namely, our workers can't live on $10 / week, and we can't compete with a country that controls its internal economy so that it feeds free market economies while preventing their result locally (ie, US companies would buy up all food etc in China until the price went up, if China didn't restrict that type of activity) You need to look far beyond what you're considering for the real reason of China's "success". The answer is a GAT, applied at the border, on everything. It also will fix another local problem, while raising prices of goods from artificially cheap places like China.
At the risk of tl;dr, the initial sets of paras are more about backend browser threading than IPC. IPC is a whole different ball of wax from mere threading. Nothing there states anything about how the JS engine is run.
Generally, JS is single-threaded, especially within a page. You'll note there's no "thread" type, class, nor anything else you can access from within the browser (to stay on topic, Node.js etc are not in scope) You can achieve multi-threading via Ajax, which does run a separate I/O and "thread" in JS, and can cause some interesting behavior (race conditions) if you have multiple Ajax calls affecting the same element set. Going further - the I/O for cookies is handled underneath the JS engine, the JS engine itself, at least as far as page rendering and UI interaction goes, is single threaded. That's important, because that's the entire problem mentioned several posts ago. If you want to state "but wait, I know I can set the download threads to 'x'" that's true, and that's the JS engine handing off URL requests to the underlying network I/O stack, which is where the multithreading resides. The JS Engine merrily continues its processing until it has either 1) finished processing everything in the current stack and is waiting on I/O to return, or 2) it has run out of network I/O threads to pass requests to. (Simplistic, I know, again, far too much to write otherwise) Essentially that's how it works under the covers. So even in Chrome, which I haven't tested this hypothesis, the network I/O could be limited by a single network I/O process if they're sharing... via IPC. Again, that would be under the covers and not at a JS engine level.
I have had more fun than I can relate here about digging through various JS frameworks to debug web 2.0 issues in various browsers. Chrome's 1 process per page is a nice simple way to achieve separation so that 1 page cannot affect another, which is a browser sandbox design anyways. Only parent/child pages should be able to talk to one another, and IIRC in Chrome, those run in the same process.
To summarize - as far as the JS engine goes, there is no IPC, and even in Chrome, the JS engine is single-threaded for rendering/UI interaction and still subject to locking. It's just 1 page that's affected instead of everything in the browser.