"0 g" is a specifier of acceleration magnitude (gravitational acceleration included).
Except tidal forces[1] an object in an orbiting spacecraft experiences an external acceleration (relative to the craft) of exactly zero magnitude. When not ignoring them we get really small accelerations on the order of.000001g or 1 ug [2], hence microgravity.
Furthermore for the purposes of local experiments, it is correct to treat the craft as a proper inertial reference frame, despite appearing substantially non-internal by a distant observer. (This is the Einstein equivalence principle.)
[1] and things like the very small air resistance of the near-vacuum [2] the "u" should be micro, but I cannot convince slashcode to not strip that out, even html encoding seems to not work.
Odd. I find that for communication with parties I already know, voice is by far the fastest. Textual communication is often more convient though, especially when dealing with companies or unfamiliar individuals.
With if there is a clear distinction between sources and sinks, then surely the same thing applies. If your current routing patterns cannot handle the incoming packets, you drop some of the sources, while you reconfigure to handle routing to a destination (if possible), then start accepting data from the sources again.
The problem though is that in data networks the very same connections are both. In Power networks that cannot be the case since they cancel, but incoming packets do not cancel out outgoing packets. Also unlike the power network which is likely to be able to quickly heal if they go down, with BGP it is all too common to have have plenty of restrictions on permitted routes between distinct networks, so all too often a break takes a long time to heal because somebody has to manually reconfigure...:-(
The problem is not the F, it is the ND. Non-discriminatory pricing that is non-zero discriminates against work developed in any any non-commercial setting. Even if we were talking about absurdly low prices (fractions of a cent per unit), work developed academically or by individuals utilizing the patent cannot be distributed widely since an academic or individual would not have the resources to track distribution, and if work is popular would not have the money to pay the royalties in the first place. Basically FRAND forces commercialization.
For better or worse you don't need to lie to get out of jury duty. You just need to convince either party that leaving you on the jury is too risky, and thus be removed by peremptory strike. Intelligence alone can be a reason for being dismissed. Otherwise things like mannerisms or word choice may cause you be removed without ever once lying.
That is bullshit. Not only is there a clearly visible skip button in the image on that story, but I just created my fourth google account (via IGoogle) and never even saw that screen.
If I go to http://www.google.com/accounts to create one, I am indeed forced to get GMail, but I can still skip the Google profile by unchecking the "personalization" checkbox on step one.
Furthermore, once you have a Google account with Gmail it is possible to delete the Gmail account while keeping the rest of the account (you must supply a non-Google email address, which will become you new sign-in email address.)
The preferred name would indeed be "iron(II) oxide". The name "iron monoxide" is however correct for a purely stoichiometric name. Such a name does not indicate the exact number of each element in a molecule, only the relative numbers. It also does not indicate the bonding in any way.
As of the IUPAC Redbook 2005, the preferred name would be "Iron(II) Oxide", however the name "Iron Monoxide" is a valid stoichiometric name for the substance.
The classic name "Ferrous Oxide" is no longer considered acceptable. I quote from Table III's second definition of the suffix "-ous":
Ending formerly added to stems of element names to indicate a lower oxidation state, e.g. ferrous chloride, cuprous oxide, cerous hydroxide. Such names are no longer acceptable.
The "-ous" suffix is still permitted as part of acid names like "seleninous acid", or "arsorous acid".
One it provides support for using BrowserID with browsers that do not have built-in BrowserID support. It does this by providing a JavaScript polyfill used by relying sites. This script uses the central server to provide a UI for login. This needs to be centralized, since the providers also use javascript function in the browser, and they must use the same fallback service as browsers without built-in support.
Two it provides a service to validate the assertions. This does not need to be centralized. A relying site can do this itself or use service provided by any third party it trusts. In the long term relying sites should do this themselves, but having an simple third party service makes this easier to implement an relying site.
Actually it works fine with multiple devices/compters/browsers.
One finished it will work like this: You click login. The website calls a javascript function provided by your browser. If you pick/enter an email adress.
If you have not used the adress before the browser generates a cryptographic key pair. It contacts your email provider. If you are already signed in the provider simply signs the browser's generated public key (which includes the email address). A signed public key is also known as a certificate. If you are not signed into the email provider's site, you get redirected there, you sign in, and then the certificate generation continues.
If you have used the email address before, and the certificate is expired, the above is also done to generate a new certificate. If the certicate is not expired, it can be used without even contacting your email provider.
Your browser generates a message that contains the domain name of the site you are signing into, an and expiration date. It signs it with the private key corresponding to the certificate. It then sends the signed message, and your certificate to the website. The website verifies the message has its domain name, is not expired, that it was signed with the included certificate. Then it extracts the email address from the certificate, and uses that to get the public key of your email provider, and it verifies your certifiate with that key.
If all the verifications worked out the website now has proof that you control that email address, and you are signed in.
Oh, last but not least, while I kept saying email address, and email provider, it does not need to be a real working email address, it just needs to be shaped like one. An id like "twittername@twitter.com" could work too if Twitter decided to become an BrowserID provider.
The email address is most definitely transmitted to the relying party. Indeed the fetching your email adress along with proof of you owning it is the whole point. That is why the function the site calls to kick the whole process off was originally called "navigator.id.getVerifiedEmail" (although it is now renamed "navigator.id.get").
The system can work two ways. Either the browser requests a long-lasting certificate from the email provider, which means no re-authenticating until that certificate expires, or it can request a short-lived certificate, and you re-authenticate every time. However even re-authenticating every time is no big deal, since if you are already signed in with your email provider, the entire process is silent.
The way it is supposed to work (eventually) 1. User clicks sing-in link on website.
2. Website calls a Javascript function that is implemented by the browser. They pass in a callback function that takes one argument (described later).
3. The user selects an email address from a list in the browser, or chooses to add a new email address.
4. The browser checks a with the email provider (via http, and a well known location (like robots.txt or favicon.ico)) to verify that they support BrowserID. We will assume the email provider does support BrowserID. The response includes a public key for the Provider, and a provisioning url.
5. The browser opens the provisioning URL in a hidden iframe.
6. The provisioning page requests the email address from the browser.
7. If the user is already signed in goto step 10.
8. The provider indicates that the user is not signed in, and tell the browser the URL of the sign in-page, which the browser shows to the user.
9. The user signs in as normal.
10. The provisioning page asks the browser to generate a cryptographic key pair.
11. The browser passes the public key to the provisioning page, which passes it to the provider's server, which signs it (with a short expiration time) , replies with the signature , which is passed back to the browser.
12. The browser creates an assertion, which is the domain name of the site the user is trying to sign into, the email address, and a short expiration time, signed with the browser-generated private key. The assertion also includes the signed public key.
13. The browser passes the assertion into the callback, which passes it to the website's server.
14. The website's server extracts the email, fetches the provider's public key, much like the browser did. The server validates the assertion includes its domain name, and is not expired, and was signed by the included public key. It also verifies that the public key is not expired. If so, it extracts the email address, and uses it to fetch the email provider's public key. It uses that to verify that the email provider signed the public key found in the assertion.
15. The user is considered signed in by the website.
How this looks to the user In the most common case, the user is already signed in with their email provider, so the user sees themselves clicking on the login link, picking their email adress, and that's it. They are signed in.
How this currently works Currently there is no browser support. There is a centralized location that provides a JavaScript polyfill and associated website allowing the system to be used without browser support. Both the provider's provisioning page, and the Relying website's page must use this polyfill, and this must be one one centralized location, since both would need to use the script from the same site in order for this to work.
Currently there are also no email providers that provide this support, so a central provider is used as a fallback. This provider must be in a centralized location, since both the browser/polyfill-site and the relying party must agree on the fallback provider. This provider does the only thing it can to verify ownership of a third party email address, which is sending a standard challange email to the address, which the user will access and reply to.
The only real reason Google is keeping Sketch-Up is that it ties into Google Earth.
Unfortunately Google Earth's cancellation is already planned. As soon Google can reliably replicate enough of its functionality into the WebGL version of Google Maps, Google Earth will be gone.
In the plus side, at least there is some hope of Google releasing the Sketch-Up source, since it is not tied into any of Google's core technologies.
Oh I agree that the job description for "Line Installers and Repairers" is much closer to the job the installer does than the description for "Radio and Telecommunications Equipment Installers and Repairers".
The problem is that the salary figures for "Line Installers and Repairers" are much, much higher than what the average installer makes.
A tiny number of top "Line Installers and Repairers" might actually qualify for the title "network specialist", but only because they are overqualified for their job.
I've never heard of such a condition (blind when walking, can see when stationary) before. What causes that?
However, if the rules were written properly you would not be excluded simply because you could not reliably walk X distance to a building unassisted without taking frequent (and dangerous) breaks to allow you to see.
You are right about black and whie rules, but that would be easy to fix in this case. Simply have the rules for automatic approval be black and white, permitting others to petition a board of multiple physicians if they believe they should be allowed the placard, despite not meeting the automatic eligibility rules. If the board of physicians concur that granting a placard would be beneficial (rather than abusive), they would be empowered to do so.
That is simple and fair, yet would cut back on quite a bit of abuse. (In my area people with no real disability are known to doctor shop until they find one what is willing to prescribe them a placard. A board of multiple physicians would mitigate such abuse.)
Actually that description is for the people who work on the distribution lines (on the poles, or buried).
Most of the discussion here has been about the installers, who work outdoors to connect the line to the internal coax network, and then indoors to place and connect a cable box and cable modem and connect them to the existing coax network. They fall between several BLS categories, and rarely earn more than $29k per year and often far less (far below linemen). They do not require any degree, and have minimal training, thus being literally unskilled labor.
I agree that they are not a "Basic Electrician". I would argue though that they are a strict subset of an electrician. Any decent electrician should be able to run coax, or Cat 5 cable without much difficulty (assuming they have the tools, and have had even 5 minutes of instruction on crimping coax ends, etc).
That said even a very successful "cable guy" could not be expected to do much of the diagnostic and design work that an electrician does on a daily basis.
The design is that once any legitimate query needs access to the DET layer, the proxy has the database replace the whole column with the one with RND stripped off, leaving just DET. They mention that it would be possible to re-encrypt back to DET if after a long enough period of time if no further queries occurred that needed it.
It would completely kill performance if they always restored the RND layer, since much of the overhead of the system comes from pulling and decrypting columns, so that operation must be as infrequent as possible. When the columns are already using the required level, the overhead is limited to the latency of the proxy, plus the time required to encrypt the constants in the sql and translate the table and column names to the obfuscated ones.
Thus in steady state, the amount of work done by the database server itself is nearly identical to what would be done on the same database without encryption. That is the key to the speed.
I have no idea if what you say is true, and I don't really care because Ron Paul is a loon, and that alone is reason enough not to vote for him.
However surely he knows that nothing short of a constitutional amendment can prevent the Supreme Court from overturning state laws. If congress passed such a law purporting to limit the supreme court, they would just rule that law unconstitutional when the question comes up. And they would be quite right to do so.
Sure judicial review is not explicitly mentioned in the constitution, but part of the job of any court is to determine what law applies when two or more laws contradict (or appear to contradict) each other. Judicial review is nothing more than doing what courts have always done, which is rule on such disputes of law.
The scheme they use is reference 4, which is available online at http://www.cc.gatech.edu/~aboldyre/papers/bclo.pdf (found with simple Google search for the paper's title: Order-Preserving Symmetric Encryption)
My bigger issue is with a chosen plain-text attack. If a column is currently stored in say DET, and you have full view of the database, and you arrange for say an insertion of a row with some specific value, now you know all the rows with that value. Even if you can only arrange for a "select * from diagnosis where ICD9Code='042'" , even if it has a couple of unrelated joins, there will only be a couple of strings, and you can probably narrow it down to the one string you want. With that you now know which rows indicate a diagnosis of AIDS. A serious information leak. Combine that with a few other chosen plaintext queries, like one involving the patient Joe Smith, and before long, you have enough to check if Joe Smith has AIDS!
I'm pretty sure that was the same exchange. Quoted in full:
Scotty: Shunt the deuterium from the main cryo-pump to the auxiliary tank. La Forge: Er, the tank can't withstand that kind of pressure. Scotty: [laughs] Where'd you... where'd you get that idea? La Forge: What do you mean, where did I get that idea? It's in the impulse engine specifications. Scotty: Regulation 42/15 - Pressure Variances on the IRC Tank Storage? La Forge: Yeah. Scotty: Forget it. I wrote it. A good engineer is always a wee bit conservative, at least on paper. Just bypass the secondary cut-off valve and boost the flow. It'll work.
No, you're wrong. "hone in on" is not a phrase, except when used mistakenly. When you're saying "ho?e in on", you always want an 'm'.
Well sometimes you want an "l", plus an extra "e" at the end of the the phase.
Also in a nautical context you can use a "v", as in "the cable was hove in on the windlass". "hove up" is the more common version, but on a ship "in" would be just as valid a direction for heaving an anchor cable.
1575.42MHz is first of all just the carrier frequency. All useful signals have a non-zero band width. Second, GPS receivers are required by design to not filter out adjacent spectrum because the actual received frequency will differ due to Doppler shift.
GPS signals are extraordinarily weak. The cell towers are over 1000 times as powerful as the actual satellites, and the satellites are so much further away, that the LightSpped signal at a GPS device is often a billion times stronger than the GPS signal. Considering how close the frequencies are that means that an incredibly strong filter is needed, and it must be designed to have near zero attenuation of actual GPS signals, since they are so weak already.
GPS receivers have historically been designed assuming that the nearby signals like those in LightSpeed's frequencies would not be substantially stronger than a GPS signal, since that frequency range was reserved for satellite communications. Even if they had been designed with LightSpeed in mind, it is virtually impossible to design a filter that would work and not harm the performance of GPS without substantially increasing the size of the receiver.
I'm honestly shocked that up to 25% of the receivers did not experience any interference. These were probably large receivers that already had excellent filtering, but which would be completely unsuitable for use in say a cell phone.
The annoying parts are definitely the contextual ribbon tabs and just how hidden some features become. Honestly, if they had completely rearranged the menus, I would find that less obnoxious because at least it is easy to exhaustively search a menu.
With the ribbon it is hard because each ribbon group can have a sub menu, a ribbon gallery can have menu items, and a ribbon button can have a sub-menu. This makes it much, much harder to exhaustively search to find a feature that was hidden someplace obscure.
Slashdot Mirror
"0 g" is a specifier of acceleration magnitude (gravitational acceleration included).
Except tidal forces[1] an object in an orbiting spacecraft experiences an external acceleration (relative to the craft) of exactly zero magnitude. When not ignoring them we get really small accelerations on the order of .000001g or 1 ug [2], hence microgravity.
Furthermore for the purposes of local experiments, it is correct to treat the craft as a proper inertial reference frame, despite appearing substantially non-internal by a distant observer. (This is the Einstein equivalence principle.)
[1] and things like the very small air resistance of the near-vacuum
[2] the "u" should be micro, but I cannot convince slashcode to not strip that out, even html encoding seems to not work.
Odd. I find that for communication with parties I already know, voice is by far the fastest. Textual communication is often more convient though, especially when dealing with companies or unfamiliar individuals.
With if there is a clear distinction between sources and sinks, then surely the same thing applies. If your current routing patterns cannot handle the incoming packets, you drop some of the sources, while you reconfigure to handle routing to a destination (if possible), then start accepting data from the sources again.
The problem though is that in data networks the very same connections are both. In Power networks that cannot be the case since they cancel, but incoming packets do not cancel out outgoing packets. Also unlike the power network which is likely to be able to quickly heal if they go down, with BGP it is all too common to have have plenty of restrictions on permitted routes between distinct networks, so all too often a break takes a long time to heal because somebody has to manually reconfigure ... :-(
The problem is not the F, it is the ND. Non-discriminatory pricing that is non-zero discriminates against work developed in any any non-commercial setting. Even if we were talking about absurdly low prices (fractions of a cent per unit), work developed academically or by individuals utilizing the patent cannot be distributed widely since an academic or individual would not have the resources to track distribution, and if work is popular would not have the money to pay the royalties in the first place. Basically FRAND forces commercialization.
For better or worse you don't need to lie to get out of jury duty. You just need to convince either party that leaving you on the jury is too risky, and thus be removed by peremptory strike. Intelligence alone can be a reason for being dismissed. Otherwise things like mannerisms or word choice may cause you be removed without ever once lying.
That is bullshit. Not only is there a clearly visible skip button in the image on that story, but I just created my fourth google account (via IGoogle) and never even saw that screen.
If I go to http://www.google.com/accounts to create one, I am indeed forced to get GMail, but I can still skip the Google profile by unchecking the "personalization" checkbox on step one.
Furthermore, once you have a Google account with Gmail it is possible to delete the Gmail account while keeping the rest of the account (you must supply a non-Google email address, which will become you new sign-in email address.)
The preferred name would indeed be "iron(II) oxide". The name "iron monoxide" is however correct for a purely stoichiometric name. Such a name does not indicate the exact number of each element in a molecule, only the relative numbers. It also does not indicate the bonding in any way.
See the IUPAC Red Book 2005 for more details.
FeO has not been Ferrous Oxide in many years.
As of the IUPAC Redbook 2005, the preferred name would be "Iron(II) Oxide", however the name "Iron Monoxide" is a valid stoichiometric name for the substance.
The classic name "Ferrous Oxide" is no longer considered acceptable. I quote from Table III's second definition of the suffix "-ous":
Ending formerly added to stems of element names to indicate a lower oxidation state, e.g.
ferrous chloride, cuprous oxide, cerous hydroxide. Such names are no longer acceptable.
The "-ous" suffix is still permitted as part of acid names like "seleninous acid", or "arsorous acid".
The centralized server does 2 things.
One it provides support for using BrowserID with browsers that do not have built-in BrowserID support. It does this by providing a JavaScript polyfill used by relying sites. This script uses the central server to provide a UI for login. This needs to be centralized, since the providers also use javascript function in the browser, and they must use the same fallback service as browsers without built-in support.
Two it provides a service to validate the assertions. This does not need to be centralized. A relying site can do this itself or use service provided by any third party it trusts. In the long term relying sites should do this themselves, but having an simple third party service makes this easier to implement an relying site.
Actually it works fine with multiple devices/compters/browsers.
One finished it will work like this:
You click login. The website calls a javascript function provided by your browser. If you pick/enter an email adress.
If you have not used the adress before the browser generates a cryptographic key pair. It contacts your email provider. If you are already signed in the provider simply signs the browser's generated public key (which includes the email address). A signed public key is also known as a certificate. If you are not signed into the email provider's site, you get redirected there, you sign in, and then the certificate generation continues.
If you have used the email address before, and the certificate is expired, the above is also done to generate a new certificate. If the certicate is not expired, it can be used without even contacting your email provider.
Your browser generates a message that contains the domain name of the site you are signing into, an and expiration date. It signs it with the private key corresponding to the certificate. It then sends the signed message, and your certificate to the website. The website verifies the message has its domain name, is not expired, that it was signed with the included certificate. Then it extracts the email address from the certificate, and uses that to get the public key of your email provider, and it verifies your certifiate with that key.
If all the verifications worked out the website now has proof that you control that email address, and you are signed in.
Oh, last but not least, while I kept saying email address, and email provider, it does not need to be a real working email address, it just needs to be shaped like one. An id like "twittername@twitter.com" could work too if Twitter decided to become an BrowserID provider.
The email address is most definitely transmitted to the relying party. Indeed the fetching your email adress along with proof of you owning it is the whole point. That is why the function the site calls to kick the whole process off was originally called "navigator.id.getVerifiedEmail" (although it is now renamed "navigator.id.get").
The system can work two ways. Either the browser requests a long-lasting certificate from the email provider, which means no re-authenticating until that certificate expires, or it can request a short-lived certificate, and you re-authenticate every time. However even re-authenticating every time is no big deal, since if you are already signed in with your email provider, the entire process is silent.
The way it is supposed to work (eventually)
1. User clicks sing-in link on website.
2. Website calls a Javascript function that is implemented by the browser. They pass in a callback function that takes one argument (described later).
3. The user selects an email address from a list in the browser, or chooses to add a new email address.
4. The browser checks a with the email provider (via http, and a well known location (like robots.txt or favicon.ico)) to verify that they support BrowserID. We will assume the email provider does support BrowserID. The response includes a public key for the Provider, and a provisioning url.
5. The browser opens the provisioning URL in a hidden iframe.
6. The provisioning page requests the email address from the browser.
7. If the user is already signed in goto step 10.
8. The provider indicates that the user is not signed in, and tell the browser the URL of the sign in-page, which the browser shows to the user.
9. The user signs in as normal.
10. The provisioning page asks the browser to generate a cryptographic key pair.
11. The browser passes the public key to the provisioning page, which passes it to the provider's server, which signs it (with a short expiration time) , replies with the signature , which is passed back to the browser.
12. The browser creates an assertion, which is the domain name of the site the user is trying to sign into, the email address, and a short expiration time, signed with the browser-generated private key. The assertion also includes the signed public key.
13. The browser passes the assertion into the callback, which passes it to the website's server.
14. The website's server extracts the email, fetches the provider's public key, much like the browser did. The server validates the assertion includes its domain name, and is not expired, and was signed by the included public key. It also verifies that the public key is not expired. If so, it extracts the email address, and uses it to fetch the email provider's public key. It uses that to verify that the email provider signed the public key found in the assertion.
15. The user is considered signed in by the website.
How this looks to the user
In the most common case, the user is already signed in with their email provider, so the user sees themselves clicking on the login link, picking their email adress, and that's it. They are signed in.
How this currently works
Currently there is no browser support. There is a centralized location that provides a JavaScript polyfill and associated website allowing the system to be used without browser support. Both the provider's provisioning page, and the Relying website's page must use this polyfill, and this must be one one centralized location, since both would need to use the script from the same site in order for this to work.
Currently there are also no email providers that provide this support, so a central provider is used as a fallback. This provider must be in a centralized location, since both the browser/polyfill-site and the relying party must agree on the fallback provider. This provider does the only thing it can to verify ownership of a third party email address, which is sending a standard challange email to the address, which the user will access and reply to.
The only real reason Google is keeping Sketch-Up is that it ties into Google Earth.
Unfortunately Google Earth's cancellation is already planned. As soon Google can reliably replicate enough of its functionality into the WebGL version of Google Maps, Google Earth will be gone.
In the plus side, at least there is some hope of Google releasing the Sketch-Up source, since it is not tied into any of Google's core technologies.
Oh I agree that the job description for "Line Installers and Repairers" is much closer to the job the installer does than the description for "Radio and Telecommunications Equipment Installers and Repairers".
The problem is that the salary figures for "Line Installers and Repairers" are much, much higher than what the average installer makes.
A tiny number of top "Line Installers and Repairers" might actually qualify for the title "network specialist", but only because they are overqualified for their job.
I've never heard of such a condition (blind when walking, can see when stationary) before. What causes that?
However, if the rules were written properly you would not be excluded simply because you could not reliably walk X distance to a building unassisted without taking frequent (and dangerous) breaks to allow you to see.
You are right about black and whie rules, but that would be easy to fix in this case. Simply have the rules for automatic approval be black and white, permitting others to petition a board of multiple physicians if they believe they should be allowed the placard, despite not meeting the automatic eligibility rules. If the board of physicians concur that granting a placard would be beneficial (rather than abusive), they would be empowered to do so.
That is simple and fair, yet would cut back on quite a bit of abuse. (In my area people with no real disability are known to doctor shop until they find one what is willing to prescribe them a placard. A board of multiple physicians would mitigate such abuse.)
Actually that description is for the people who work on the distribution lines (on the poles, or buried).
Most of the discussion here has been about the installers, who work outdoors to connect the line to the internal coax network, and then indoors to place and connect a cable box and cable modem and connect them to the existing coax network. They fall between several BLS categories, and rarely earn more than $29k per year and often far less (far below linemen). They do not require any degree, and have minimal training, thus being literally unskilled labor.
I agree that they are not a "Basic Electrician". I would argue though that they are a strict subset of an electrician. Any decent electrician should be able to run coax, or Cat 5 cable without much difficulty (assuming they have the tools, and have had even 5 minutes of instruction on crimping coax ends, etc).
That said even a very successful "cable guy" could not be expected to do much of the diagnostic and design work that an electrician does on a daily basis.
The design is that once any legitimate query needs access to the DET layer, the proxy has the database replace the whole column with the one with RND stripped off, leaving just DET. They mention that it would be possible to re-encrypt back to DET if after a long enough period of time if no further queries occurred that needed it.
It would completely kill performance if they always restored the RND layer, since much of the overhead of the system comes from pulling and decrypting columns, so that operation must be as infrequent as possible. When the columns are already using the required level, the overhead is limited to the latency of the proxy, plus the time required to encrypt the constants in the sql and translate the table and column names to the obfuscated ones.
Thus in steady state, the amount of work done by the database server itself is nearly identical to what would be done on the same database without encryption. That is the key to the speed.
I have no idea if what you say is true, and I don't really care because Ron Paul is a loon, and that alone is reason enough not to vote for him.
However surely he knows that nothing short of a constitutional amendment can prevent the Supreme Court from overturning state laws. If congress passed such a law purporting to limit the supreme court, they would just rule that law unconstitutional when the question comes up. And they would be quite right to do so.
Sure judicial review is not explicitly mentioned in the constitution, but part of the job of any court is to determine what law applies when two or more laws contradict (or appear to contradict) each other. Judicial review is nothing more than doing what courts have always done, which is rule on such disputes of law.
The scheme they use is reference 4, which is available online at http://www.cc.gatech.edu/~aboldyre/papers/bclo.pdf (found with simple Google search for the paper's title: Order-Preserving Symmetric Encryption)
My bigger issue is with a chosen plain-text attack. If a column is currently stored in say DET, and you have full view of the database, and you arrange for say an insertion of a row with some specific value, now you know all the rows with that value. Even if you can only arrange for a "select * from diagnosis where ICD9Code='042'" , even if it has a couple of unrelated joins, there will only be a couple of strings, and you can probably narrow it down to the one string you want. With that you now know which rows indicate a diagnosis of AIDS. A serious information leak. Combine that with a few other chosen plaintext queries, like one involving the patient Joe Smith, and before long, you have enough to check if Joe Smith has AIDS!
Your point is correct, but your math looks a little off.
850 mHz= 850 milliHertz = .85 Hz = a little under once per second.
2500 mHz = 2500 milliHertz = 2.5 Hz = two and a half times per second.
Still very low bitrates, especially since we are talking about the carrier frequency, so the data rate will be much lower.
I'm pretty sure that was the same exchange. Quoted in full:
Scotty: Shunt the deuterium from the main cryo-pump to the auxiliary tank.
La Forge: Er, the tank can't withstand that kind of pressure.
Scotty: [laughs] Where'd you... where'd you get that idea?
La Forge: What do you mean, where did I get that idea? It's in the impulse engine specifications.
Scotty: Regulation 42/15 - Pressure Variances on the IRC Tank Storage?
La Forge: Yeah.
Scotty: Forget it. I wrote it. A good engineer is always a wee bit conservative, at least on paper. Just bypass the secondary cut-off valve and boost the flow. It'll work.
No, you're wrong. "hone in on" is not a phrase, except when used mistakenly. When you're saying "ho?e in on", you always want an 'm'.
Well sometimes you want an "l", plus an extra "e" at the end of the the phase.
Also in a nautical context you can use a "v", as in "the cable was hove in on the windlass". "hove up" is the more common version, but on a ship "in" would be just as valid a direction for heaving an anchor cable.
1575.42MHz is first of all just the carrier frequency. All useful signals have a non-zero band width. Second, GPS receivers are required by design to not filter out adjacent spectrum because the actual received frequency will differ due to Doppler shift.
GPS signals are extraordinarily weak. The cell towers are over 1000 times as powerful as the actual satellites, and the satellites are so much further away, that the LightSpped signal at a GPS device is often a billion times stronger than the GPS signal. Considering how close the frequencies are that means that an incredibly strong filter is needed, and it must be designed to have near zero attenuation of actual GPS signals, since they are so weak already.
GPS receivers have historically been designed assuming that the nearby signals like those in LightSpeed's frequencies would not be substantially stronger than a GPS signal, since that frequency range was reserved for satellite communications. Even if they had been designed with LightSpeed in mind, it is virtually impossible to design a filter that would work and not harm the performance of GPS without substantially increasing the size of the receiver.
I'm honestly shocked that up to 25% of the receivers did not experience any interference. These were probably large receivers that already had excellent filtering, but which would be completely unsuitable for use in say a cell phone.
The annoying parts are definitely the contextual ribbon tabs and just how hidden some features become. Honestly, if they had completely rearranged the menus, I would find that less obnoxious because at least it is easy to exhaustively search a menu.
With the ribbon it is hard because each ribbon group can have a sub menu, a ribbon gallery can have menu items, and a ribbon button can have a sub-menu. This makes it much, much harder to exhaustively search to find a feature that was hidden someplace obscure.