You realize that the proper way to use nuclear fuel is have a breeding reactor where the waste is reprocessed on-site, with everything still burnable (the vast majority) separated from the true waste, and fed back in.
The design I am most familar with is the IFR, which was intended to e built into say the side of a mountain. Once the reactor is started, no fuel ever enters or leaves the facility. The design would have burned a wide range of fuels, including waste from previous generation reactors.
The actual wastes not fed back in were intended to be be either extremely long half-life waste (277,000 to 15 million years), which would actually be less radioactive than uranium ore, or much shorter half-life waste (~5-90 years).
The result: the mixture would decay to the radiation levels found in raw ore in only 200 years, rather than the tens of thousands of years of most currently operating reactors.
Although the IFR project was abandoned by the US government, GE-Hitachi is actively developing a version of it, albeit one that requires off-site storage of the final waste (but only for 200 years).
Also some other modern reactor designs share many of the important characteristics of the IFR.
Interesting. Out of curiosity, hoe confident are you that the jury would have spent as much time and as much attention to detail had you not been on it?
It's hard to say, but enough of the other jurors had similar questions and issues as I did, they just didn't have the same understanding of probability as I did. Specifically, if 25% of test results are false positives; and that is true for all the tests run; it means that after four independent, different tests the chance of a false positive is about 2%, despite the defense attorney's constant "the test are unreliable" argument. At the start, the jury was split on guilt; even without me I think they would have had the same amount of deliberation on the most serious charge. My argument gave weight to the "the defendant failed all four tests" argument from a logical POV; they probably would have reached the same conclusion but have less of a factual basis for it.
That is quite good to hear. Few accounts I have heard before had juries sound as logical, rather than primarily emotional. The latter is a very disturbing idea to me.
One thing to keep in mind though, is that while you calculated the probability of 4 false positives on the test,to actually calculate probability of the accused having committed the act, given the four positives would depend on knowing the probability that the accused did it in the absence of the tests.
You may well be aware of that though, and at least implicitly determined that any other evidence available indicated a high enough initial probability of guilt.
Oddly enough, my main input was on a relatively minor charge where the law was very unclear - I eventually convinced the holdouts that if the law is not clear about what constitutes an offense you can't find someone guilty since the law, as written, both allowed and disallowed the conduct in question. I guess all that time "rules lawyering" during boardgames while in college wasn't wasted after all.
You may be aware though, that technically the way the law works is that whichever part was newer would apply in the event of contradiction in a statute. Of course if the contradictory portions were introduced at the same time, then your conclusion is indisputably correct. There though is also other long standing legal concepts that would support the notion that if the codified law is inconsistent, regardless of the order of the statutes it consists of, then it would be unreasonable to ever find somebody guilty in the ambiguous part. The law can be rather strange like that.
But you can add more towers if you turn the power down, and space them evenly. Picture this: you have a fiber running to every apartment, and every business, and every floor of every skyscraper in the city. To each of those fibers you attach a femptocell.
However unlike current femptocell offerings for consumers, the company owns both the cell and the fiber, exactly like they own the the current cells, and the backhauls for them.
Unimaginably expensive but not by any means physically impossible.
In that case, the power for each of those cells could be set extremely low, such that a phone is pretty much never is range of more than 3 to 5 much like current towers. Each femptocell could theoretically provide all the bandwidth (in both senses) that a current tower provides, because they are so low power that the overlaps are similar to the overlaps of current towers. Except in exceptionally crowded places like a subway, of sporting event, or a packed bar, there would be relatively few people on average in the range of each cell, and they could split all the data-type bandwith that the frequency-type bandwidth can supply between those small number of phones.
My point there was to show that adding a boatload (actually a fleet-load) of towers and turning the power way down, you can scale. (Except that you can never scale well when people are packed like sardines!) What is important though is that you must turn down the power, and carefully control the placement to keep the amount of overlap between towers reasonable.
Now as for the phone companies, they could obviously improve the even in the high density areas, but it is true that they cannot improve by only adding a small number of towers. If they wanted to add a small numer of towers, they would need to reposition all the others and adjust power to minimize overlap,and moving existing towers is VERY expensive.
Or they could perhaps triple (roughly) the number of towers, with strategic placement, so they don't have to move existing towers, but tripling the number of towers simultaneously throughout a city is also VERY expensive (doing that in NYC would bankrupt them).
Your conclusion is true in general though, given the insane costs of increasing tower density in a useful way, there is little they can do.
Interesting. Out of curiosity, hoe confident are you that the jury would have spent as much time and as much attention to detail had you not been on it?
I mean I would expect that most people on Slashdot to work to ensure a proper fact based finding (as opposed to a purely emotional one, or one based on facts but only on a very cursory overview of them) so their presence may have a significant impact on how the jury operates.
I would hope many juries do try to do a good job. Unfortunately it is definitely the case that at least some juries simply don't care, and want to be done as quickly as possible. I wish i had some good numbers on this, but that would be very hard to come by.
Actually the main yahoo search site does use bing right now. I just performed a random search on yahoo, and at the very bottom I see the words "Powered by Bing".
LTE's maximum data rates assume things like using 4x4 antennae (or at least 2x2), and the full 20MHz bandwidth per connection. In reality these early devices are likely using a 1x1 antenna and are most likely using one of the lower bandwidth options.
I could be wrong though, I've not actually checked the specs of the device in question.
That depends very much on the VCS. Many modern VCS's have the property that any completely checkout has a distinct revision identifier, meaning that you can always go back the the same version of the entire codebase. Furthermore, there are Version control systems out there that do not permit whole repository branching, but do support per file or per directory (non-recursive) branching. Those are rather esoteric systems, but they do exist.
True, there is nothing that absolutely requires a flat LCD. I'm guessing that the trickiest part would likely be the illumination of the bent portion. It would be a bit challenging to get that to not appear either darker or lighter than the rest of the screen.
Unless you are using a VCS that does mandatory per file locking, then you are conceptually branching every time you check out code, since before you check the code back in, somebody else could come along and check in other changes.
Granted that most version control systems don't label a working directory as a branch. The only real difference is that a working directory does not have a series of commits while a ranch does. Of course, even that is not much of a difference, since good practice would be to examine your working directory' changes and manually break it up into a series of commits as required.
GCC's code respositories are hosted on gcc.gnu.org, a machine also known as sourceware.org, which is owned and operated by Redhat and provides hosting for basically the entire GNU toolchain (automake, autoconf, binutils, GCC, gdb, glibc, and libstdc++)[1].
This attack therefore would not be able to modify the GCC sources.
[1] Notably not present are GNU's bison, libtool, m4 and make.
In case you don't know, the root zone is a text file that is only a little over 200 kB. It has only a handful (relatively speaking) of domains. The official root zone is published, and you could set up your own DNS server that serves it. [1]
The important servers are the gtld zone servers. Those are the ones with millions of domains. They are the ones that the federal government is meddling with. They handle insane volumes of traffic [2]. To the best of my knowledge the gTLD zone files are not publicly published, meaning that it would not be possible to set up an alternative version of it like you seem to be proposing.
Footnotes:
[1] Granted, you would need to set up your recursive DNS resolver to use your root server, but that is easy enough to do. Even DNSsec would work fine in such, since DNSsec only authenticates the response, and does not care who sent it.
[2] Thankfully the DNS system has caching, or it would be cost prohibitive to continue to run the GTLD servers.
Interesting. So the studied effect is likely part of the general "too clean is a bad thing" effect. That general effect would also include other effects like "immune system training"[1], and the killing off of the the "good" bacteria found on the body.
[1] More precisely: having B-cell around from previous infections that happen to encode antibodies similar to one that will work for this infection, such that you find the
Very true. If one wants to create C# code that is cross platform compatible, I strongly recommend either doing the development on Linux using mono, so you cannot inadvertently use classes that mono does not support, or in the alternative, develop on windows with a continuous integration system that tries to build the software on Linux under mono after every check-in.
Doing either of those can save you some headaches later, and neither is particularly difficult.
Still easy for the vast majority of devices. Just place a patch in the market. The trick would be distributing different versions of the new browser executable to each android version. However, the way the market works makes that entirely possible.
Then the only devices that remain are those without the market. Google can contact the OEMs of such devices, and give them the source code patch. It is then no longer Google's responsibility, but rather the OEM's responsibility to actually issue the patch.
You are correct but that post is a bit misleading.
My understanding is that the Treasury orders the production of coins and bills, but they are not money at that time (i.e. the treasury is not permitted to just use the new coins and bills). Instead the Federal Reserve purchases the bills at production cost from the treasury, and then it is money.
My understanding is that it is also responsible for introducing and removing coins, although these it purchases at face value from the treasury. Never the less, doing so still adds currency to circulation, as where there was only $100 in paper money in the Fed, there is now $100 in paper money in the Treasury, and $100 of coins in the fed, for a total of $200 of currency in circulation.
The Federal Reserve can remove money from circulation, and add new money at will. Thus if it has old bills in its "vault" it can have them destroyed, and it need not immediately get replacement bills.
However, actually getting the bills into circulation is not particularly easy. While for example new bills can e sent to banks when they make a withdrawal, that is not increasing the money since they previously deposited old money.
About the only way new money can be introduced in his fashion is by using it to buy Government securities, which it never redeems, and thus has inserted new currency into circulation. Unfortunately though, that technically means that introducing new money requires governmental debt, although I don't believe those bonds are normally considered part of the national debt.
Of course, all of that above is based on my cobbled together understanding, and i could be very wrong in several spots. If I am, I would be interested in knowing the true story.
That is absurd, because modern hardware can establish 1500 sessions per core per second if using 1024-bit RSA keys[1]. While going to 2048 bits will take longer, you are claiming it will take over 16 times longer to establish a 2048 RSA session. That does not sound right to me.
There is a very easy way to patch it. Don't let public pages redirect to "content://com.android.htmlfileprovider/*".
While it is fully intended that public pages be able to access other content providers, there is no valid need for them to be able to access html files stored on the device, especially since local html files are trusted higher than public html files.
In the attack, the server forces an html page to be downloaded by using an incorrect content-type. It then redirects to that local page via the content provider. Given the higher trust of local html pages, it an load the targeted file, and posts it to the malicious server.
Where does it clearly state that it is split between peak and off peak? The contracts don't even mention the quotas, so the only information is on the plan pages.
That definitely sounds like there is no peak vs off-peak differentiation.
I also see: "The monthly quota allocation on Internode Easy Naked services is counted as the sum of both uploads and downloads".
That statement certainly looks like it is saying that there is only one combined quota, not separate upload and download quotas. If there were separate upload and download quotas, then that statement would qualify as deliberately misleading advertising. I'm not an Australian, but I would presume there are laws against misleading advertisements in Australia.
All governments love to do that. Even the US (especially at the State Level) tends to privitize quite a bit. There are very few public utilities left. I mean I find it patently absurd that prisons have even been privatized.
Basically if a state/local public utility could be profitable, it is usually privatized. Those that cannot turn a profit are often, but not always kept public. If it would not be profitable the only option is for the government to pay the difference. The easy way to do that is to run it directly. For example, most fire departments are run that way, as are nearly all police departments[1].
There are cases of unprofitable entities being privatized though, becoming government contractors, dependent on the state to be profitable. One such example of this is Privately operated prisons. The contracting styles does leave the government ultimately in charge, but it still seems like an invitation for abuse.
Interestingly, at the Federal level the US has multiple public utilities. For example, Amtrak. Although not a government agency, Amtrak is a privately held company with the US Treasury as the majority shareholder, and is dependent on Government subsidies to remain profitable.
We also have the USPS (Postal Service) that could theoretically be be disbanded in favor of private non-subsidized letter carriers, although special regulations would be necessary if the flat-rate universal service for first-class mail was desired. On the other hand, the USPS generally has fewer serious complaints than the other parcel carriers, and is among the must trusted of the government agencies, which is likely one of the main reasons it is kept public.
Footnotes: [1] There are a few police departments that are funded at least in part by non governmental entities. For example, some private universities have an actual Police department, which is funded in part by the university, since it has additional security duties relative to other departments.
Reading between the lines a bit, the main goal of the fabric is to instanctiate a set of accelerators useful to your application. Stock acellerators are provided. Alternatively custom acellerators could be written. Certain other peripherals, such as say a PS/2 controller, or USB controller, or Gigabit Ethernet MAC could also be instantiated, but some of the most likely desired ones will exist as hard logic.
Not a bad way to support basic SOC system, especially since the emphasis on the programmable logic is on the accelerators. The system would not be as configurable as the old Vertex offerings, but one can get better specs (speed, power dissipation, etc) on peripherals that nearly every design will use by having them be hard logic.
With a bit of work, one could probably split the fabric up into several distinct "slots", using floor-planning to constrict place and route, and instantiate each stock accelerator in each slot, generating partial reconfiguration bit streams, for each slot/accelerator combination. Then the application code could literally just pick a set of desired accelerators, and instantiate them. A latter portion of the application could come along later, and swap some out for others that would be useful, etc.
That really cannot be easily done with the peripherals though, since they would be using the external pins, and there is no easy way to make the PCB traces configurable at run time.
In many setups, we are talking ten or hundreds of milliseconds. Not bad for starting an application, but unless apps claim exclusive us of the FPGA, then to quote Andy Dodd's post above: "context switching would be a real bitch".
Ha ha, yeah, oddly enough the multitasking and context-switching issues *had* occurred to me; I'm actually surprised that it would be that fast, to be honest!
Partial/Full reconfiguration speeds are very dependent on the FPGA architecture, but one designed for say column-wise partial configuration shouldn't have too much trouble reconfiguring a column in 200 to 300 ms. Once you have gone that far, it is not too much harder to allow reconfiguring multiple columns in parallel, and you would then end up with times like those I mentioned. One should be able to improve that speed significantly with various tricks. Many of those tricks are at the expense of a bit of die area, but that may well be a necessary trade-off for reconfigurable processors.
Neither. FPGAs don't work by opcodes, or anything remotely similar.
While it is possible to have a CPU design where additional CPU Opcodes can be added by the FPGA, and they would work just like any other opcode[1], but this is not such a design. The design here is a standard Atom CPU, connected to the FPGA by a a 1x PCIE bus. The FPGA could be configured to act like any possible PCIE component, with internal digital logic, and using the GPIO pins to interface with something else you (the PCB designer) put on the motherboard.
Footnote: [1] Practical implementations of such a system may have the new opcodes take more cycles than a native opcode, as the CPU's clock speed may be to great for the FPGA, but you may well be able to have the new opcode take 10 clock cycles, or so, to perform some function that would normally take 100 operations or more.
What would be possible in such a system would very much be dependent on the design of the platform. A platform that exposes only the ALU stage of the pipeline would only work particularly well for new esoteric arithmetic operations, but one could still put registers in there allowing for more complex sets of additional instructions. However if hooks into more of the CPU are exposed, then the new opcodes could potentially be more efficent, or add interesting features like virtualization extensions, and so on.
Slashdot Mirror
You realize that the proper way to use nuclear fuel is have a breeding reactor where the waste is reprocessed on-site, with everything still burnable (the vast majority) separated from the true waste, and fed back in.
The design I am most familar with is the IFR, which was intended to e built into say the side of a mountain. Once the reactor is started, no fuel ever enters or leaves the facility. The design would have burned a wide range of fuels, including waste from previous generation reactors.
The actual wastes not fed back in were intended to be be either extremely long half-life waste (277,000 to 15 million years), which would actually be less radioactive than uranium ore, or much shorter half-life waste (~5-90 years).
The result: the mixture would decay to the radiation levels found in raw ore in only 200 years, rather than the tens of thousands of years of most currently operating reactors.
Although the IFR project was abandoned by the US government, GE-Hitachi is actively developing a version of it, albeit one that requires off-site storage of the final waste (but only for 200 years).
Also some other modern reactor designs share many of the important characteristics of the IFR.
Interesting. Out of curiosity, hoe confident are you that the jury would have spent as much time and as much attention to detail had you not been on it?
It's hard to say, but enough of the other jurors had similar questions and issues as I did, they just didn't have the same understanding of probability as I did. Specifically, if 25% of test results are false positives; and that is true for all the tests run; it means that after four independent, different tests the chance of a false positive is about 2%, despite the defense attorney's constant "the test are unreliable" argument. At the start, the jury was split on guilt; even without me I think they would have had the same amount of deliberation on the most serious charge. My argument gave weight to the "the defendant failed all four tests" argument from a logical POV; they probably would have reached the same conclusion but have less of a factual basis for it.
That is quite good to hear. Few accounts I have heard before had juries sound as logical, rather than primarily emotional. The latter is a very disturbing idea to me.
One thing to keep in mind though, is that while you calculated the probability of 4 false positives on the test,to actually calculate probability of the accused having committed the act, given the four positives would depend on knowing the probability that the accused did it in the absence of the tests.
You may well be aware of that though, and at least implicitly determined that any other evidence available indicated a high enough initial probability of guilt.
Oddly enough, my main input was on a relatively minor charge where the law was very unclear - I eventually convinced the holdouts that if the law is not clear about what constitutes an offense you can't find someone guilty since the law, as written, both allowed and disallowed the conduct in question. I guess all that time "rules lawyering" during boardgames while in college wasn't wasted after all.
You may be aware though, that technically the way the law works is that whichever part was newer would apply in the event of contradiction in a statute. Of course if the contradictory portions were introduced at the same time, then your conclusion is indisputably correct. There though is also other long standing legal concepts that would support the notion that if the codified law is inconsistent, regardless of the order of the statutes it consists of, then it would be unreasonable to ever find somebody guilty in the ambiguous part. The law can be rather strange like that.
But you can add more towers if you turn the power down, and space them evenly. Picture this: you have a fiber running to every apartment, and every business, and every floor of every skyscraper in the city. To each of those fibers you attach a femptocell.
However unlike current femptocell offerings for consumers, the company owns both the cell and the fiber, exactly like they own the the current cells, and the backhauls for them.
Unimaginably expensive but not by any means physically impossible.
In that case, the power for each of those cells could be set extremely low, such that a phone is pretty much never is range of more than 3 to 5 much like current towers. Each femptocell could theoretically provide all the bandwidth (in both senses) that a current tower provides, because they are so low power that the overlaps are similar to the overlaps of current towers. Except in exceptionally crowded places like a subway, of sporting event, or a packed bar, there would be relatively few people on average in the range of each cell, and they could split all the data-type bandwith that the frequency-type bandwidth can supply between those small number of phones.
My point there was to show that adding a boatload (actually a fleet-load) of towers and turning the power way down, you can scale. (Except that you can never scale well when people are packed like sardines!) What is important though is that you must turn down the power, and carefully control the placement to keep the amount of overlap between towers reasonable.
Now as for the phone companies, they could obviously improve the even in the high density areas, but it is true that they cannot improve by only adding a small number of towers. If they wanted to add a small numer of towers, they would need to reposition all the others and adjust power to minimize overlap,and moving existing towers is VERY expensive.
Or they could perhaps triple (roughly) the number of towers, with strategic placement, so they don't have to move existing towers, but tripling the number of towers simultaneously throughout a city is also VERY expensive (doing that in NYC would bankrupt them).
Your conclusion is true in general though, given the insane costs of increasing tower density in a useful way, there is little they can do.
Interesting. Out of curiosity, hoe confident are you that the jury would have spent as much time and as much attention to detail had you not been on it?
I mean I would expect that most people on Slashdot to work to ensure a proper fact based finding (as opposed to a purely emotional one, or one based on facts but only on a very cursory overview of them) so their presence may have a significant impact on how the jury operates.
I would hope many juries do try to do a good job. Unfortunately it is definitely the case that at least some juries simply don't care, and want to be done as quickly as possible. I wish i had some good numbers on this, but that would be very hard to come by.
Hello, Mr underscore-ook?
(If it does not sound like fuck, the only other pronunciation I can think of is ook.)
Also I'm pretty sure you don't own _uck.org, you liar! ;D
Actually the main yahoo search site does use bing right now. I just performed a random search on yahoo, and at the very bottom I see the words "Powered by Bing".
LTE's maximum data rates assume things like using 4x4 antennae (or at least 2x2), and the full 20MHz bandwidth per connection. In reality these early devices are likely using a 1x1 antenna and are most likely using one of the lower bandwidth options.
I could be wrong though, I've not actually checked the specs of the device in question.
That depends very much on the VCS. Many modern VCS's have the property that any completely checkout has a distinct revision identifier, meaning that you can always go back the the same version of the entire codebase. Furthermore, there are Version control systems out there that do not permit whole repository branching, but do support per file or per directory (non-recursive) branching. Those are rather esoteric systems, but they do exist.
True, there is nothing that absolutely requires a flat LCD. I'm guessing that the trickiest part would likely be the illumination of the bent portion. It would be a bit challenging to get that to not appear either darker or lighter than the rest of the screen.
Well a single touch sex robot would be awkward, would it not?
Unless you are using a VCS that does mandatory per file locking, then you are conceptually branching every time you check out code, since before you check the code back in, somebody else could come along and check in other changes.
Granted that most version control systems don't label a working directory as a branch. The only real difference is that a working directory does not have a series of commits while a ranch does. Of course, even that is not much of a difference, since good practice would be to examine your working directory' changes and manually break it up into a series of commits as required.
Add to that that gcc is hosted.
GCC's code respositories are hosted on gcc.gnu.org, a machine also known as sourceware.org, which is owned and operated by Redhat and provides hosting for basically the entire GNU toolchain (automake, autoconf, binutils, GCC, gdb, glibc, and libstdc++)[1].
This attack therefore would not be able to modify the GCC sources.
[1] Notably not present are GNU's bison, libtool, m4 and make.
In case you don't know, the root zone is a text file that is only a little over 200 kB. It has only a handful (relatively speaking) of domains. The official root zone is published, and you could set up your own DNS server that serves it. [1]
The important servers are the gtld zone servers. Those are the ones with millions of domains. They are the ones that the federal government is meddling with. They handle insane volumes of traffic [2]. To the best of my knowledge the gTLD zone files are not publicly published, meaning that it would not be possible to set up an alternative version of it like you seem to be proposing.
Footnotes:
[1] Granted, you would need to set up your recursive DNS resolver to use your root server, but that is easy enough to do. Even DNSsec would work fine in such, since DNSsec only authenticates the response, and does not care who sent it.
[2] Thankfully the DNS system has caching, or it would be cost prohibitive to continue to run the GTLD servers.
Interesting. So the studied effect is likely part of the general "too clean is a bad thing" effect.
That general effect would also include other effects like "immune system training"[1], and the killing off of the the "good" bacteria found on the body.
[1] More precisely: having B-cell around from previous infections that happen to encode antibodies similar to one that will work for this infection, such that you find the
What about "a giant amount of negative reviews"?
Very true. If one wants to create C# code that is cross platform compatible, I strongly recommend either doing the development on Linux using mono, so you cannot inadvertently use classes that mono does not support, or in the alternative, develop on windows with a continuous integration system that tries to build the software on Linux under mono after every check-in.
Doing either of those can save you some headaches later, and neither is particularly difficult.
Still easy for the vast majority of devices. Just place a patch in the market. The trick would be distributing different versions of the new browser executable to each android version. However, the way the market works makes that entirely possible.
Then the only devices that remain are those without the market. Google can contact the OEMs of such devices, and give them the source code patch. It is then no longer Google's responsibility, but rather the OEM's responsibility to actually issue the patch.
You are correct but that post is a bit misleading.
My understanding is that the Treasury orders the production of coins and bills, but they are not money at that time (i.e. the treasury is not permitted to just use the new coins and bills). Instead the Federal Reserve purchases the bills at production cost from the treasury, and then it is money.
My understanding is that it is also responsible for introducing and removing coins, although these it purchases at face value from the treasury. Never the less, doing so still adds currency to circulation, as where there was only $100 in paper money in the Fed, there is now $100 in paper money in the Treasury, and $100 of coins in the fed, for a total of $200 of currency in circulation.
The Federal Reserve can remove money from circulation, and add new money at will. Thus if it has old bills in its "vault" it can have them destroyed, and it need not immediately get replacement bills.
However, actually getting the bills into circulation is not particularly easy. While for example new bills can e sent to banks when they make a withdrawal, that is not increasing the money since they previously deposited old money.
About the only way new money can be introduced in his fashion is by using it to buy Government securities, which it never redeems, and thus has inserted new currency into circulation. Unfortunately though, that technically means that introducing new money requires governmental debt, although I don't believe those bonds are normally considered part of the national debt.
Of course, all of that above is based on my cobbled together understanding, and i could be very wrong in several spots. If I am, I would be interested in knowing the true story.
That is absurd, because modern hardware can establish 1500 sessions per core per second if using 1024-bit RSA keys[1]. While going to 2048 bits will take longer, you are claiming it will take over 16 times longer to establish a 2048 RSA session. That does not sound right to me.
[1] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
There is a very easy way to patch it. Don't let public pages redirect to "content://com.android.htmlfileprovider/*".
While it is fully intended that public pages be able to access other content providers, there is no valid need for them to be able to access html files stored on the device, especially since local html files are trusted higher than public html files.
In the attack, the server forces an html page to be downloaded by using an incorrect content-type. It then redirects to that local page via the content provider. Given the higher trust of local html pages, it an load the targeted file, and posts it to the malicious server.
Where does it clearly state that it is split between peak and off peak? The contracts don't even mention the quotas, so the only information is on the plan pages.
On http://www.internode.on.net/residential/broadband/adsl/easy_naked/plans/ I see the following text:
"Massive 'Any Time' monthly quota - measured as the total of downloads plus uploads. No 'peak' or 'off-peak' restrictions - you can use the Internet whenever you like!"
That definitely sounds like there is no peak vs off-peak differentiation.
I also see: "The monthly quota allocation on Internode Easy Naked services is counted as the sum of both uploads and downloads".
That statement certainly looks like it is saying that there is only one combined quota, not separate upload and download quotas. If there were separate upload and download quotas, then that statement would qualify as deliberately misleading advertising. I'm not an Australian, but I would presume there are laws against misleading advertisements in Australia.
All governments love to do that. Even the US (especially at the State Level) tends to privitize quite a bit. There are very few public utilities left. I mean I find it patently absurd that prisons have even been privatized.
Basically if a state/local public utility could be profitable, it is usually privatized. Those that cannot turn a profit are often, but not always kept public. If it would not be profitable the only option is for the government to pay the difference. The easy way to do that is to run it directly. For example, most fire departments are run that way, as are nearly all police departments[1].
There are cases of unprofitable entities being privatized though, becoming government contractors, dependent on the state to be profitable. One such example of this is Privately operated prisons. The contracting styles does leave the government ultimately in charge, but it still seems like an invitation for abuse.
Interestingly, at the Federal level the US has multiple public utilities. For example, Amtrak. Although not a government agency, Amtrak is a privately held company with the US Treasury as the majority shareholder, and is dependent on Government subsidies to remain profitable.
We also have the USPS (Postal Service) that could theoretically be be disbanded in favor of private non-subsidized letter carriers, although special regulations would be necessary if the flat-rate universal service for first-class mail was desired. On the other hand, the USPS generally has fewer serious complaints than the other parcel carriers, and is among the must trusted of the government agencies, which is likely one of the main reasons it is kept public.
Footnotes:
[1] There are a few police departments that are funded at least in part by non governmental entities. For example, some private universities have an actual Police department, which is funded in part by the university, since it has additional security duties relative to other departments.
Interesting.
Reading between the lines a bit, the main goal of the fabric is to instanctiate a set of accelerators useful to your application. Stock acellerators are provided. Alternatively custom acellerators could be written. Certain other peripherals, such as say a PS/2 controller, or USB controller, or Gigabit Ethernet MAC could also be instantiated, but some of the most likely desired ones will exist as hard logic.
Not a bad way to support basic SOC system, especially since the emphasis on the programmable logic is on the accelerators. The system would not be as configurable as the old Vertex offerings, but one can get better specs (speed, power dissipation, etc) on peripherals that nearly every design will use by having them be hard logic.
With a bit of work, one could probably split the fabric up into several distinct "slots", using floor-planning to constrict place and route, and instantiate each stock accelerator in each slot, generating partial reconfiguration bit streams, for each slot/accelerator combination. Then the application code could literally just pick a set of desired accelerators, and instantiate them. A latter portion of the application could come along later, and swap some out for others that would be useful, etc.
That really cannot be easily done with the peripherals though, since they would be using the external pins, and there is no easy way to make the PCB traces configurable at run time.
In many setups, we are talking ten or hundreds of milliseconds. Not bad for starting an application, but unless apps claim exclusive us of the FPGA, then to quote Andy Dodd's post above: "context switching would be a real bitch".
Ha ha, yeah, oddly enough the multitasking and context-switching issues *had* occurred to me; I'm actually surprised that it would be that fast, to be honest!
Partial/Full reconfiguration speeds are very dependent on the FPGA architecture, but one designed for say column-wise partial configuration shouldn't have too much trouble reconfiguring a column in 200 to 300 ms. Once you have gone that far, it is not too much harder to allow reconfiguring multiple columns in parallel, and you would then end up with times like those I mentioned. One should be able to improve that speed significantly with various tricks. Many of those tricks are at the expense of a bit of die area, but that may well be a necessary trade-off for reconfigurable processors.
Neither. FPGAs don't work by opcodes, or anything remotely similar.
While it is possible to have a CPU design where additional CPU Opcodes can be added by the FPGA, and they would work just like any other opcode[1], but this is not such a design. The design here is a standard Atom CPU, connected to the FPGA by a a 1x PCIE bus. The FPGA could be configured to act like any possible PCIE component, with internal digital logic, and using the GPIO pins to interface with something else you (the PCB designer) put on the motherboard.
Footnote:
[1] Practical implementations of such a system may have the new opcodes take more cycles than a native opcode, as the CPU's clock speed may be to great for the FPGA, but you may well be able to have the new opcode take 10 clock cycles, or so, to perform some function that would normally take 100 operations or more.
What would be possible in such a system would very much be dependent on the design of the platform. A platform that exposes only the ALU stage of the pipeline would only work particularly well for new esoteric arithmetic operations, but one could still put registers in there allowing for more complex sets of additional instructions. However if hooks into more of the CPU are exposed, then the new opcodes could potentially be more efficent, or add interesting features like virtualization extensions, and so on.