More problematic is that vote by mail isn't private / anonymous - your actual vote is visible for all to read.
What kind of system are you using? Typically you don't just write your candidate's name on the back of a postcard. The ballot itself does not contain any voter identification. You seal the completed ballot inside a blank envelope, and then put that envelope inside another envelope labeled with your voter identification. You sign the outer envelope and mail it in. Later someone checks the identification and signature, confirms that you didn't already vote by mail or in person, and removes the sealed inner envelope—they see who voted, but not the actual votes. The outer envelopes are discarded, while the anonymous inner envelopes containing the ballots are mixed together and opened by someone else. This second person can count the votes but does not have access to the identities of the voters.
The system honestly isn't all that bad, though it does have certain vulnerabilities. Most notably, someone could watch you fill out and mail the ballot and also ensure that you are unable to reach the polls to override the mailed-in responses by voting in person.
Of course, all this effort is pointless if one can simply ask voters about their selections and reasonably expect a truthful answer. The practicality of the secret ballot fundamentally depends on voters' willingness to lie, which makes it rather dubious, morally speaking. The fact they they could lie and that there is (ideally) no way to prove that any given response is accurate means little unless a significant fraction of individuals are actually willing to defraud prospective vote-buyers, which would reflect poorly on their character and is not really a form of behavior which ought to be encouraged.
In reality though, if the voter signs the ballot (as is done in the vote-by-mail process in Oregon) and the signature matches what is in the voter registry, does it really matter? They endorsed what is selected on the ballot.
What is to say that the nominal voter didn't sign the blank ballot before handing it over to someone else, either under duress or to obtain a reward?
The only way I know of to deal with this is to allow the ballot to be secretly voided at any time (before or after it's been filed) at the request of the voter to whom it was issued. If you anticipate voter intimidation you could request an extra pre-voided ballot, indistinguishable from a real one, and hand that over instead. If you were the subject of unanticipated intimidation you could request that your original ballot be voided and vote again. Of course, this safeguard can be circumvented if the intimidator is able to keep a close watch on your activities throughout the process—at some point you need to be able to communicate with the election committee without their knowledge.
The may not be able to MITM the connection, but with the developers' signing key they could push an update out which would send the cleartext straight from the app to the FBI's servers. To avoid that attack vector you would need to disable auto-updates and only install versions (manually, after verifying the signature on the binary) which have undergone a thorough security audit by someone you trust—preferably yourself.
Please stop spouting nonsense. Your "judicial order" isn't worth the electrons it's printed on without some kind of backdoor to bypass the encryption. Issue all the "judicial orders" you want—without a backdoor built in to the system beforehand the information will stubbornly remain encrypted.
However in this case we have a tool that has proven itself over decades of use by knowledgable and skilled craftsman. A tool that can do any sort of memory checking the craftsman wishes it to, any sort of checking the "training wheels" languages do.
Sure, provided the craftsman writes verbose boilerplate code to accomplish simple tasks that other languages handle automatically—and manages to do so without introducing additional errors in the boilerplate. (More code equal more bugs.)
A tool that needlessly requires more skill and effort to accomplish the same result, without a corresponding increase in utility / expressiveness, is also a bad tool.
Qwest are apparently doing 6rd so you should be able to get v6 with them too, albeit over a tunnel.
I have this set up, and can attest that it works reasonably well. The only real problem is that (presumably unlike native IPv6) you aren't assigned a static IPv6 prefix; it's tied to your dynamic IPv4 address. Consequently, I also have a Hurricane Electric tunnel configured with a static IPv6 prefix for use in DNS. This required some complicated source-based routing rules, though, so it's not for everyone. (You can't route HE packets out over the 6rd tunnel or vice-versa, and normal routing only looks at the destination address. To make it work you have to set up multiple routing tables ("ip route table...") and select the proper one based on the source address ("ip rule add from... table...").
Of course, one could just pay extra $$$ for a static IPv4 address, which would provide a static 6rd prefix...
That would be well and fine if most IPv6 addresses didn't have a 64-bit or even 80-bit prefix, identical for everything routable at the endpoint.
That 64-bit network prefix is the equivalent of 4 billion entire IPv4 internets—and each "host" in each of those internets contains its very own set of 2**32 IPv4 internets in the 64-bit suffix. Quadrupling the number of bits from 32 to 128 means raising the number of addresses to the fourth power (2**32 vs. 2**128 = (2**32)**4). We can afford to spare a few bits for the sake of a more hierarchical and yet automated allocation policy that addresses some of the more glaring issues with IPv4, like the address conflicts which inevitably occur when merging two existing private networks.
Think of it this way: If we manage to be just half as efficient in our use of address bits compared to IPv4, it will still be enough to give every public IPv4 address its own private 32-bit IPv4 internet. Right now the vast majority of IPv6 unicast space is still classified as "reserved", so we have plenty of time to adjust our policies if it turns out that we need to be more frugal.
Then there are DHCP addressing schemes that use the MAC as part of the address, further reducing it.
Automatic address assignment (based on MAC or random addresses or whatever) comes out of the host-specific suffix, not the network prefix, so it doesn't reduce the number of usable addresses any more than the prefix alone. It does imply that you need at least a 64-bit host part in order to ensure globally uniqueness without manual assignment, but the recommended 64-bit split between network and host was already part of the standard.
1) First I would have done only countries and no other TLD.
Personally, I would have done the opposite, and demoted country-specific sites to a second-level domain like.us.gov. The Internet is an international network; forcing every domain to be classified first and foremost according to its national origin would cause needless discord. Only a small minority of sites are truly country-specific.
it could have been debian.cc or debian.de or any other that they wanted
In which case the country code would communicate zero information about the site—so why have it at all?
What might make more sense would be using registrars as TLDs (e.g. google.mm for MarkMonitor), with a convention that multiple TLDs can contain the same subdomains if and only if they mirror each other. This would tie in well with DNSSEC while also avoiding the need to defend one's domain name against scammers in a million separate TLDs. If a government just happens to run its own registrar it could use the country code for its TLD alongside non-country TLDs. The main difference from the current system would be that TLDs would be generic rather than catering to a particular kind of site, which is mostly the case in practice anyway:.com no longer implies commerce, not every.org is a non-profit,.net does not imply an ISP, etc. Instead, the TLD would imply a trust relationship; the name "google.mm" would imply looking up the "google" subdomain in the MarkMonitor domain registry, which would presumably be listed among the user's local trust anchors. If there were an alternative domain like "google.vs" (for VeriSign) it would be required to resolve to the same address.
But how would you even do that with dynamic languages, where the type can just change at runtime?
Obviously you can't, which is one of the arguments against programming in dynamically-typed (unityped) languages. This is why TypeScript exists: a statically-typed JavaScript derivative which compiles down to plain JS after proving that the types are satisfied (i.e. performing static code analysis), much as any other statically-typed languages compiles down to unityped machine code.
Furthermore, TypeScript is handling null just like Java.
No, it isn't. Both TypeScript and Java will complain about uninitialized variables, but Java will not produce an compile-time error if you set the variable to null (directly or indirectly) and then try to use it as a reference. TypeScript will, unless you explicitly check that the value is not null before using it. (Checking for null changes the type from nullable to non-null within the scope of the condition.)
declare function arbitrary(): string | null; let x: string; let y: string | null; x = arbitrary();// Error, type 'string | null' is not assignable to type 'string'. y = arbitrary();// Fine x.length;// Fine, x is non-nullable. y.length;// Error, object is possibly 'null'. if (y != null) { y.length;// Fine, y is non-null in this scope. }
A NPE means you have a bug in your code, and it's better for the app to crash than to corrupt your data, or silently just lose it.
Even better would be to detect the bug statically, at compile time, as a type error, so that your program doesn't crash at some arbitrary point later and lose all the user's data.
The point is not to eliminate the concept of nullable references, which are indeed useful for representing data which is not available. The point is to distinguish between such nullable references and references which cannot be null so that the compiler can check that all the nullable references have been properly handled and warn you about any and all potential null pointer issues in advance.
The problem isn't that the language has nullable references, it's that it doesn't have a reference type which cannot be null. A nullable reference is isomorphic to the Optional or Maybe type available in most "null-free" languages, and this certainly has perfectly legitimate uses. The issue in a language like C, Java or JavaScript is that every single operation on references takes this nullable reference type as input, and the vast majority of those operations assume that the reference will not be null and generate a runtime error otherwise. In a more principled language there would be a type distinction between a reference which may be null and a reference which cannot be null, and the programmer would need to destructure the nullable value into either null or a non-null reference before using it in operations which do not expect null. This eliminates a wide variety of common mistakes by making them type errors at compile time rather than subtle runtime errors which may or may not cause the program to crash, depending on the inputs. If the program is written correctly then this destructuring happens at the same places where you already should be checking whether the reference is null before using it, so it doesn't even make the program significantly longer. You just need to annotate your type declarations to indicate where the reference is allowed to be null.
SQL databases are actually a fairly good example of how null values should be implemented, because you can specify whether a field can or cannot be null in the table definition and this constraint will be enforced by the database.
The only part of quantum entanglement that is "instantaneous" (or "FTL") is that when one party performs its measurement, the wave functions for both of the entangled particles collapse out of their superimposed states simultaneously, no matter how far apart they might be. However, this does not communicate any information by itself; for that the two parties still need a classical channel. As you say, nothing is transferred FTL. An observer cannot tell that the wave function has collapsed without making a measurement, which would collapse the wave function anyway, and without a separate channel there is no way to know whether the other party observed the same quantum state.
What is being "communicated" FTL, without a non-FTL classical channel, is a random superposition of all the possible quantum states. That is not "random information", it's "no information". Without the classical channel you don't even know whether the holder of the other entangled particle is measuring the same quantum states, so no information is exchanged, not even information about the measured states of the entangled particles.
But sure, as a trivial special case, it is possible to exchange zero information at FTL speeds...
It's also limited to preventing States from designating their choice of currency (other than gold and/or silver) as legal tender. They can issue whatever currency they want, so long as it isn't close enough to U.S. federal currency to be considered counterfeit. They just can't make anyone accept it the way people are forced to accept an offer of full payment in legal tender to settle a debt—regardless of what currency or goods the debt may originally have been denominated in.
This is to prevent a particular state from picking some good it has in abundance (but which is in low demand), declaring it legal tender, and using it to "settle" debts at below-market rates. Somewhat ironically, this is exactly what the federal government did when it went off the gold standard and declared unbacked paper currency to be legal tender in payment of debts.
I think it was an Inspiron. Almost certainly one of the consumer lines. It had a smooth underside with no ventilation holes or visible screws, no removable battery, and few ports. (One needs to remove the rubber feet to open the case.) I don't have it with me to check the exact model.
Unless things have changed, WiFi on a decent laptop is usually implemented as a removable miniPCIe card. You can get any card you want on Ebay for $20 or less; I usually use some Intel card, I forget the model number now.
Will that work here? The last time I tried to swap out the WiFi card in a Dell laptop (fairly recent, but not an XPS) for another one from the same manufacturer (Intel) it refused to boot with the BIOS citing a problem with the WiFi card's serial number.
I like the look of this XPS 13 DE, but I wouldn't care to buy any laptop with that degree of hardware lock-down.
Which is really stupid, when you think about it. If you upload 0.1% of a file to 1,000 different peers, that's one copy shared, not 1,000. And if they all do the same (within the group) that's 1,000 copies created, not 1,000,000. But the studios manage to get away with suing 1,000 peers for 1,000 copies each, which is far more than the potential revenues even if one very generously assumes that every peer who obtains a copy of the file represents a lost sale, even before you throw in nonsense like statutory damages.
The correct liability for a single peer with a share ratio of 1.00 or less (cumulative upload less than or equal to the file size) is no more than perhaps three times the standard retail value of the work. Not $450 or $1,500 or $150,000 or $21M, no matter how many other peers were involved.
The ability to skip the line is obviously a limited resource. The park generally alternates service between the fast and slow lines to ensure both make some progress rather than following a strict priority order. If "everyone" skipped the line (because the price was set too low; or from the other P.O.V., because the park wasn't paying enough in discounts to induce people to stand in the slow line) then the fast line would just become nearly as long as the slow line and few would choose to pay the extra cost (or forego the slow-line discount) for no gain.
Yeah, that's pretty much how it works now. As it should.
Sure; this was just the basics of why QoS is important, without regard to any specific QoS policy. The proposal is to let the each customer set the QoS policy for its own traffic, rather than leaving that up to the ISP. Someone has to decide the QoS policy if protocols like VoIP are going to be usable, and when ISPs set the policy they tend to do things like prioritize their own VoIP service packets while leaving their competitors languishing in the bulk-data queue. Even if it isn't malicious, there is no reason to expect the ISP to go out of its way to benefit a competitor. And of course, not every ISP implements a fair QoS system; some prefer to simply throttle specific protocols (like BitTorrent) regardless of capacity or fairness, in part because standard QoS policies are usually based around dividing capacity between "flows" rather than customers. Protocols like BT use many flows for the same transfer, with the end result that they can obtain more than their users' fair shares of the bandwidth compared to less distributed protocols utilizing one flow at a time if the QoS rules are not implemented carefully.
One nice thing about IPv6 is that it would make it easier to allocate bandwidth fairly: one unique IPv6 prefix equals one customer.
It is nothing more than an attempt to monetize congestion, therefore removing any incentive to eliminate the congestion.
The inventive is that many people confronted with long wait times will choose to leave rather than pay extra to jump to the front of the queue. The provider could instead choose to raise the up-front entry price, thus reducing the total number of attendees and eliminating congestion that way. The "pay to skip the line" approach makes the park look more crowded, which is good for its reputation as a popular attraction, and gives visitors the ability to pay the difference with their time rather than their money, which helps out the less affluent attendees.
Don't think of it as giving preferential treatment to the wealthy; think of it as the park paying you to stand in line for a while by waiving the "skip the line fee" that would otherwise be part of the ticket price.
Because the 4K movie viewers and the hospital are paying for exactly the same Internet service plan and thus deserve equal treatment? It isn't the ISP's place to say which customer's traffic is more important. If the hospital wants priority treatment for its medical data it should pay a bit extra for the dedicated bandwidth.
So where are these packets going to be for the next or so? In storage somewhere?
Yes, exactly. In storage in the router's buffers. You have N packets in the queue and can deliver M of them in the next X ms, so you have to decide which ones to send first and which ones must wait for the next timeslice. That's QoS in a nutshell: send the low-latency packets first, then deal with the bulk data transfers. Any packets that remain unsent for too long due to congestion get dropped. Of course, you have to police the low-latency packets to make sure they don't monopolize the line. Low-latency packets are typically limited to a small fraction of the total capacity, and anything over that limit goes in the bulk data queue. You also need to ensure fairness between different customers when selecting packets to transmit from each queue.
All packets should be delivered in the shortest quickest/most appropriate route from being sent.
And they will be, but there are other packets from different sources to consider as well, and they can't all be sent at once. Ergo, a priority scheme is needed, and the QoS policy defines the priorities.
You can only control your own router, and only packets you create can have to QoS you set. The ones coming from the internet don't have your QoS set.
Right. By the time the packet reaches your router it's already been delivered, and thus much too late to set any QoS bits. Your peers would need to set the QoS for the packets they send to you.
I agree with most of your analysis but the problem is that Ireland gave illegal state aid to Apple. Apple isn't being punished it's being told to pay the taxes it always had to pay.
The taxes it always had to pay... as of the very recent ruling that redefined tax breaks which had been in common use for decades to be a form of state aid. The fact that the EU knew that this was going on and did nothing about it for a long time should grant a form of estoppel against enforcement for past violations.
It's still ex post facto even if the change is merely a novel retroactive reinterpretation of the law rather than an alteration to the written rules. If the practice had "always" been illegal then the EU (and its predecessors) would have been after Ireland and others like it decades ago rather than waiting until now to make a move. If they want to declare that such deals will be considered "state aid" in the future, fine; but they shouldn't apply that interpretation retroactively.
It is also bizarre that Ireland's "punishment" for granting illegal state aid is to be told that it must now collect an extra $21B in back taxes, thus enriching itself at Apple's expense after it already profited by luring Apple there with promises of low taxes. If this were not ex post facto—if the "tax breaks are state aid" interpretation had been in effect from the beginning, and the violation had merely remained hidden until now—a more reasonable response would be that Apple must pay the back taxes directly to the EU, with Ireland forfeiting its normal cut.
Slashdot Mirror
More problematic is that vote by mail isn't private / anonymous - your actual vote is visible for all to read.
What kind of system are you using? Typically you don't just write your candidate's name on the back of a postcard. The ballot itself does not contain any voter identification. You seal the completed ballot inside a blank envelope, and then put that envelope inside another envelope labeled with your voter identification. You sign the outer envelope and mail it in. Later someone checks the identification and signature, confirms that you didn't already vote by mail or in person, and removes the sealed inner envelope—they see who voted, but not the actual votes. The outer envelopes are discarded, while the anonymous inner envelopes containing the ballots are mixed together and opened by someone else. This second person can count the votes but does not have access to the identities of the voters.
The system honestly isn't all that bad, though it does have certain vulnerabilities. Most notably, someone could watch you fill out and mail the ballot and also ensure that you are unable to reach the polls to override the mailed-in responses by voting in person.
Of course, all this effort is pointless if one can simply ask voters about their selections and reasonably expect a truthful answer. The practicality of the secret ballot fundamentally depends on voters' willingness to lie, which makes it rather dubious, morally speaking. The fact they they could lie and that there is (ideally) no way to prove that any given response is accurate means little unless a significant fraction of individuals are actually willing to defraud prospective vote-buyers, which would reflect poorly on their character and is not really a form of behavior which ought to be encouraged.
In reality though, if the voter signs the ballot (as is done in the vote-by-mail process in Oregon) and the signature matches what is in the voter registry, does it really matter? They endorsed what is selected on the ballot.
What is to say that the nominal voter didn't sign the blank ballot before handing it over to someone else, either under duress or to obtain a reward?
The only way I know of to deal with this is to allow the ballot to be secretly voided at any time (before or after it's been filed) at the request of the voter to whom it was issued. If you anticipate voter intimidation you could request an extra pre-voided ballot, indistinguishable from a real one, and hand that over instead. If you were the subject of unanticipated intimidation you could request that your original ballot be voided and vote again. Of course, this safeguard can be circumvented if the intimidator is able to keep a close watch on your activities throughout the process—at some point you need to be able to communicate with the election committee without their knowledge.
The may not be able to MITM the connection, but with the developers' signing key they could push an update out which would send the cleartext straight from the app to the FBI's servers. To avoid that attack vector you would need to disable auto-updates and only install versions (manually, after verifying the signature on the binary) which have undergone a thorough security audit by someone you trust—preferably yourself.
Please stop spouting nonsense. Your "judicial order" isn't worth the electrons it's printed on without some kind of backdoor to bypass the encryption. Issue all the "judicial orders" you want—without a backdoor built in to the system beforehand the information will stubbornly remain encrypted.
However in this case we have a tool that has proven itself over decades of use by knowledgable and skilled craftsman. A tool that can do any sort of memory checking the craftsman wishes it to, any sort of checking the "training wheels" languages do.
Sure, provided the craftsman writes verbose boilerplate code to accomplish simple tasks that other languages handle automatically—and manages to do so without introducing additional errors in the boilerplate. (More code equal more bugs.)
A tool that needlessly requires more skill and effort to accomplish the same result, without a corresponding increase in utility / expressiveness, is also a bad tool.
Qwest are apparently doing 6rd so you should be able to get v6 with them too, albeit over a tunnel.
I have this set up, and can attest that it works reasonably well. The only real problem is that (presumably unlike native IPv6) you aren't assigned a static IPv6 prefix; it's tied to your dynamic IPv4 address. Consequently, I also have a Hurricane Electric tunnel configured with a static IPv6 prefix for use in DNS. This required some complicated source-based routing rules, though, so it's not for everyone. (You can't route HE packets out over the 6rd tunnel or vice-versa, and normal routing only looks at the destination address. To make it work you have to set up multiple routing tables ("ip route table ...") and select the proper one based on the source address ("ip rule add from ... table ...").
Of course, one could just pay extra $$$ for a static IPv4 address, which would provide a static 6rd prefix...
HFT does not imply criminality.
That would be well and fine if most IPv6 addresses didn't have a 64-bit or even 80-bit prefix, identical for everything routable at the endpoint.
That 64-bit network prefix is the equivalent of 4 billion entire IPv4 internets—and each "host" in each of those internets contains its very own set of 2**32 IPv4 internets in the 64-bit suffix. Quadrupling the number of bits from 32 to 128 means raising the number of addresses to the fourth power (2**32 vs. 2**128 = (2**32)**4). We can afford to spare a few bits for the sake of a more hierarchical and yet automated allocation policy that addresses some of the more glaring issues with IPv4, like the address conflicts which inevitably occur when merging two existing private networks.
Think of it this way: If we manage to be just half as efficient in our use of address bits compared to IPv4, it will still be enough to give every public IPv4 address its own private 32-bit IPv4 internet. Right now the vast majority of IPv6 unicast space is still classified as "reserved", so we have plenty of time to adjust our policies if it turns out that we need to be more frugal.
Then there are DHCP addressing schemes that use the MAC as part of the address, further reducing it.
Automatic address assignment (based on MAC or random addresses or whatever) comes out of the host-specific suffix, not the network prefix, so it doesn't reduce the number of usable addresses any more than the prefix alone. It does imply that you need at least a 64-bit host part in order to ensure globally uniqueness without manual assignment, but the recommended 64-bit split between network and host was already part of the standard.
1) First I would have done only countries and no other TLD.
Personally, I would have done the opposite, and demoted country-specific sites to a second-level domain like .us.gov. The Internet is an international network; forcing every domain to be classified first and foremost according to its national origin would cause needless discord. Only a small minority of sites are truly country-specific.
it could have been debian.cc or debian.de or any other that they wanted
In which case the country code would communicate zero information about the site—so why have it at all?
What might make more sense would be using registrars as TLDs (e.g. google.mm for MarkMonitor), with a convention that multiple TLDs can contain the same subdomains if and only if they mirror each other. This would tie in well with DNSSEC while also avoiding the need to defend one's domain name against scammers in a million separate TLDs. If a government just happens to run its own registrar it could use the country code for its TLD alongside non-country TLDs. The main difference from the current system would be that TLDs would be generic rather than catering to a particular kind of site, which is mostly the case in practice anyway: .com no longer implies commerce, not every .org is a non-profit, .net does not imply an ISP, etc. Instead, the TLD would imply a trust relationship; the name "google.mm" would imply looking up the "google" subdomain in the MarkMonitor domain registry, which would presumably be listed among the user's local trust anchors. If there were an alternative domain like "google.vs" (for VeriSign) it would be required to resolve to the same address.
But how would you even do that with dynamic languages, where the type can just change at runtime?
Obviously you can't, which is one of the arguments against programming in dynamically-typed (unityped) languages. This is why TypeScript exists: a statically-typed JavaScript derivative which compiles down to plain JS after proving that the types are satisfied (i.e. performing static code analysis), much as any other statically-typed languages compiles down to unityped machine code.
Furthermore, TypeScript is handling null just like Java.
No, it isn't. Both TypeScript and Java will complain about uninitialized variables, but Java will not produce an compile-time error if you set the variable to null (directly or indirectly) and then try to use it as a reference. TypeScript will, unless you explicitly check that the value is not null before using it. (Checking for null changes the type from nullable to non-null within the scope of the condition.)
A NPE means you have a bug in your code, and it's better for the app to crash than to corrupt your data, or silently just lose it.
Even better would be to detect the bug statically, at compile time, as a type error, so that your program doesn't crash at some arbitrary point later and lose all the user's data.
The point is not to eliminate the concept of nullable references, which are indeed useful for representing data which is not available. The point is to distinguish between such nullable references and references which cannot be null so that the compiler can check that all the nullable references have been properly handled and warn you about any and all potential null pointer issues in advance.
The problem isn't that the language has nullable references, it's that it doesn't have a reference type which cannot be null. A nullable reference is isomorphic to the Optional or Maybe type available in most "null-free" languages, and this certainly has perfectly legitimate uses. The issue in a language like C, Java or JavaScript is that every single operation on references takes this nullable reference type as input, and the vast majority of those operations assume that the reference will not be null and generate a runtime error otherwise. In a more principled language there would be a type distinction between a reference which may be null and a reference which cannot be null, and the programmer would need to destructure the nullable value into either null or a non-null reference before using it in operations which do not expect null. This eliminates a wide variety of common mistakes by making them type errors at compile time rather than subtle runtime errors which may or may not cause the program to crash, depending on the inputs. If the program is written correctly then this destructuring happens at the same places where you already should be checking whether the reference is null before using it, so it doesn't even make the program significantly longer. You just need to annotate your type declarations to indicate where the reference is allowed to be null.
SQL databases are actually a fairly good example of how null values should be implemented, because you can specify whether a field can or cannot be null in the table definition and this constraint will be enforced by the database.
Thank you. That is exactly what I said.
The only part of quantum entanglement that is "instantaneous" (or "FTL") is that when one party performs its measurement, the wave functions for both of the entangled particles collapse out of their superimposed states simultaneously, no matter how far apart they might be. However, this does not communicate any information by itself; for that the two parties still need a classical channel. As you say, nothing is transferred FTL. An observer cannot tell that the wave function has collapsed without making a measurement, which would collapse the wave function anyway, and without a separate channel there is no way to know whether the other party observed the same quantum state.
What is being "communicated" FTL, without a non-FTL classical channel, is a random superposition of all the possible quantum states. That is not "random information", it's "no information". Without the classical channel you don't even know whether the holder of the other entangled particle is measuring the same quantum states, so no information is exchanged, not even information about the measured states of the entangled particles.
But sure, as a trivial special case, it is possible to exchange zero information at FTL speeds...
It's also limited to preventing States from designating their choice of currency (other than gold and/or silver) as legal tender. They can issue whatever currency they want, so long as it isn't close enough to U.S. federal currency to be considered counterfeit. They just can't make anyone accept it the way people are forced to accept an offer of full payment in legal tender to settle a debt—regardless of what currency or goods the debt may originally have been denominated in.
This is to prevent a particular state from picking some good it has in abundance (but which is in low demand), declaring it legal tender, and using it to "settle" debts at below-market rates. Somewhat ironically, this is exactly what the federal government did when it went off the gold standard and declared unbacked paper currency to be legal tender in payment of debts.
I think it was an Inspiron. Almost certainly one of the consumer lines. It had a smooth underside with no ventilation holes or visible screws, no removable battery, and few ports. (One needs to remove the rubber feet to open the case.) I don't have it with me to check the exact model.
Unless things have changed, WiFi on a decent laptop is usually implemented as a removable miniPCIe card. You can get any card you want on Ebay for $20 or less; I usually use some Intel card, I forget the model number now.
Will that work here? The last time I tried to swap out the WiFi card in a Dell laptop (fairly recent, but not an XPS) for another one from the same manufacturer (Intel) it refused to boot with the BIOS citing a problem with the WiFi card's serial number.
I like the look of this XPS 13 DE, but I wouldn't care to buy any laptop with that degree of hardware lock-down.
as X IP numbers connected = amount of shares
Which is really stupid, when you think about it. If you upload 0.1% of a file to 1,000 different peers, that's one copy shared, not 1,000. And if they all do the same (within the group) that's 1,000 copies created, not 1,000,000. But the studios manage to get away with suing 1,000 peers for 1,000 copies each, which is far more than the potential revenues even if one very generously assumes that every peer who obtains a copy of the file represents a lost sale, even before you throw in nonsense like statutory damages.
The correct liability for a single peer with a share ratio of 1.00 or less (cumulative upload less than or equal to the file size) is no more than perhaps three times the standard retail value of the work. Not $450 or $1,500 or $150,000 or $21M, no matter how many other peers were involved.
The ability to skip the line is obviously a limited resource. The park generally alternates service between the fast and slow lines to ensure both make some progress rather than following a strict priority order. If "everyone" skipped the line (because the price was set too low; or from the other P.O.V., because the park wasn't paying enough in discounts to induce people to stand in the slow line) then the fast line would just become nearly as long as the slow line and few would choose to pay the extra cost (or forego the slow-line discount) for no gain.
Yeah, that's pretty much how it works now. As it should.
Sure; this was just the basics of why QoS is important, without regard to any specific QoS policy. The proposal is to let the each customer set the QoS policy for its own traffic, rather than leaving that up to the ISP. Someone has to decide the QoS policy if protocols like VoIP are going to be usable, and when ISPs set the policy they tend to do things like prioritize their own VoIP service packets while leaving their competitors languishing in the bulk-data queue. Even if it isn't malicious, there is no reason to expect the ISP to go out of its way to benefit a competitor. And of course, not every ISP implements a fair QoS system; some prefer to simply throttle specific protocols (like BitTorrent) regardless of capacity or fairness, in part because standard QoS policies are usually based around dividing capacity between "flows" rather than customers. Protocols like BT use many flows for the same transfer, with the end result that they can obtain more than their users' fair shares of the bandwidth compared to less distributed protocols utilizing one flow at a time if the QoS rules are not implemented carefully.
One nice thing about IPv6 is that it would make it easier to allocate bandwidth fairly: one unique IPv6 prefix equals one customer.
It is nothing more than an attempt to monetize congestion, therefore removing any incentive to eliminate the congestion.
The inventive is that many people confronted with long wait times will choose to leave rather than pay extra to jump to the front of the queue. The provider could instead choose to raise the up-front entry price, thus reducing the total number of attendees and eliminating congestion that way. The "pay to skip the line" approach makes the park look more crowded, which is good for its reputation as a popular attraction, and gives visitors the ability to pay the difference with their time rather than their money, which helps out the less affluent attendees.
Don't think of it as giving preferential treatment to the wealthy; think of it as the park paying you to stand in line for a while by waiving the "skip the line fee" that would otherwise be part of the ticket price.
Because the 4K movie viewers and the hospital are paying for exactly the same Internet service plan and thus deserve equal treatment? It isn't the ISP's place to say which customer's traffic is more important. If the hospital wants priority treatment for its medical data it should pay a bit extra for the dedicated bandwidth.
So where are these packets going to be for the next or so? In storage somewhere?
Yes, exactly. In storage in the router's buffers. You have N packets in the queue and can deliver M of them in the next X ms, so you have to decide which ones to send first and which ones must wait for the next timeslice. That's QoS in a nutshell: send the low-latency packets first, then deal with the bulk data transfers. Any packets that remain unsent for too long due to congestion get dropped. Of course, you have to police the low-latency packets to make sure they don't monopolize the line. Low-latency packets are typically limited to a small fraction of the total capacity, and anything over that limit goes in the bulk data queue. You also need to ensure fairness between different customers when selecting packets to transmit from each queue.
All packets should be delivered in the shortest quickest/most appropriate route from being sent.
And they will be, but there are other packets from different sources to consider as well, and they can't all be sent at once. Ergo, a priority scheme is needed, and the QoS policy defines the priorities.
You can only control your own router, and only packets you create can have to QoS you set. The ones coming from the internet don't have your QoS set.
Right. By the time the packet reaches your router it's already been delivered, and thus much too late to set any QoS bits. Your peers would need to set the QoS for the packets they send to you.
I agree with most of your analysis but the problem is that Ireland gave illegal state aid to Apple. Apple isn't being punished it's being told to pay the taxes it always had to pay.
The taxes it always had to pay... as of the very recent ruling that redefined tax breaks which had been in common use for decades to be a form of state aid. The fact that the EU knew that this was going on and did nothing about it for a long time should grant a form of estoppel against enforcement for past violations.
It's still ex post facto even if the change is merely a novel retroactive reinterpretation of the law rather than an alteration to the written rules. If the practice had "always" been illegal then the EU (and its predecessors) would have been after Ireland and others like it decades ago rather than waiting until now to make a move. If they want to declare that such deals will be considered "state aid" in the future, fine; but they shouldn't apply that interpretation retroactively.
It is also bizarre that Ireland's "punishment" for granting illegal state aid is to be told that it must now collect an extra $21B in back taxes, thus enriching itself at Apple's expense after it already profited by luring Apple there with promises of low taxes. If this were not ex post facto—if the "tax breaks are state aid" interpretation had been in effect from the beginning, and the violation had merely remained hidden until now—a more reasonable response would be that Apple must pay the back taxes directly to the EU, with Ireland forfeiting its normal cut.