Most of the catastrophic coverage plans I see in the exchange (for 27 year-old) are in the $90-200 range. If someone "never goes to the doctor, ever", then the deductible doesn't really matter that much.
HDHP is not the same as Catastrophic.
"Marketplace catastrophic plans cover 3 annual primary care visits and preventive services at no cost."
Try "language of life", quite a few hits. It's a fairly common phrase referring to the specific encoding of amino acids into codons, plus the stop codons. If you didn't recognize the phrase to start with, you probably shouldn't be criticizing it for being dumbed-down.
4 letters (base pairs), "sets of 3 letters called codons". "Although there are 64 ways of combining 4 letters...", in that context, is clear and correct.
I'm also disappointed that no real effort was made to push for a single-payer system. I don't particularly LIKE what came out of it, but that simply means it needs to be improved, not scrapped. One option would be to add back the "public option" to the exchanges, a Medicare-For-All offering.
If she never goes to the doctor, maybe she should get Catastrophic coverage (if she's under 30), especially if she doesn't qualify for any subsidies (which don't apply to Catastrophic plans; out-of-pocket subsidies only apply to Silver plans).
You can't get any subsidies because you're already covered by an employer plan.
Why are you comparing your costs (after your employer pays most of it) on your current insurance to the full price of a plan on the exchange? You don't need to buy anything on the exchange, you're already covered.
Doing that would be the "spiteful" thing, actually. A static web page on a single server is about as foolproof as you can get, and at least gives you positive feedback that your link isn't dead or bogus. Just hanging for a while, then getting back "server not responding" would be much worse.
All I was saying is that, while you CAN have a different port when you're connecting to a different address/port, there's no need to (when the internal address/port is the same). Since there's no need to, and it's easier to use a single mapping table (mapping internal IP/port to an external port, regardless of what it's connecting to), I'd think that would be the solution most (cheap) routers would use (the kind that also would only have one external IP address).
As I said, I've never actually bothered writing the bit of code to test to see which routers do what in this regard. I'm sort of surprised that no one has ever simply proposed a standard for doing NAT that way, which would allow any router that uses that method to be easy to do a mediated direct connect.
I've never actually looked at the specific mappings a NAT router uses, but I've thought about how to do a connection between two hosts, each behind their own NAT (and yes, I know there are standards and solutions and all, this was just an exercise).
I'd think the obvious solution to how to map port numbers for NAT would be to map each host/port pair to a single random external port, regardless of the address it's sending/receiving to/from. That way you have just one lookup table for the mapping each way. IF the NAT router does that, then all you do is connect to a common server, which notes your external IP address/port and passes that on to the other party (and vice versa). If you then re-use the same port # on the two hosts, it would then map to the same external port number (since it's still active).
This would work for UDP and TCP. You'd still need to get through the firewall if the router is doing stateful blocking (which is easy to get around - there ought to be a connect_to low level call to do that, but easy enough to do a listen/connect on both sides).
Now, I realize that NAT routers could do the mapping in any of a myriad ways, but since most of them are really simple, I'd think most of them would use the really simple and obvious mapping.
If this just happens to be one of the things that is covered by the patents in question, I can say with assurance that it IS obvious; I've never read about how to do it, I've never looked at the patent, but I came up with that years ago after thinking about the problem for a few minutes. I've never tested it to see if it actually works with real equipment (nor, if it does work at all, what range of equipment it would work on).
Also quite a few Lua interpreters, of varying quality.
See Codea, not only is it a full development environment, you can apparently use it to produce a working standalone app. Look at the first item in their forum for a list of apps in the App Store developed with it.
As for calculators, I vastly prefer RPN, and I have no problems finding RPN calculators for iPad, along with unit conversions (including up-to-date currency rates). I need to look up to see if there's an iOS version of the units program, that's still the gold standard for conversion programs (and is still distributed as part of OSX).
User replaceable battery? How? I don't have any real problems with battery life yet, but I'm not aware that it can be replaced when it eventually reaches end of life.
Referring here only to the E-ink versions (Simple Touch and Glow), they did a lot of things right. Organizing your books is the weakest part, the book shelf implementation is really weak. The Kindle Paper White sounds like it's better hardware wise than the Glow, but not by a lot. My main issue with the Glow is the durability of the screen compared to the unlit Simple Touch.
Kobo sounds really good, especially the higher-resolution larger screen E-ink Aura, but all the social media oriented aspects of it are a bit of a turn-off, and it sounds like they have some real design issues with battery life, auto-power-off and sleep behavior. NOOK seems to get this right.
Ability to boot off of the external microSD card is also a big selling point for me on the NOOK. If they come out with (and don't screw up) a new version using the newer screen technology that's in the Aura, I'd buy it first chance I got (probably end up buying two, in fact, and pass on our current NOOKs to family).
I agree. It sounds like the big mistake was combining the Most Favored Nation clause with telling publishers that the agency model wouldn't move forward unless most/all the other publishers agreed.
Perhaps what Apple should have done is just offered the agency model, with the MFN clause, as an option to the publishers, along with a traditional wholesale/retail model. Then they could do a couple things: negotiate with each publisher to lower the wholesale price, perhaps while also selling at a loss, and getting dumping charges brought against Amazon.
Much has been made of how "Amazon had to raise their prices". No, they didn't. They could have continued to offer e-books for $9.99. All the MFN clause said was that then the publishers would have to lower their price through Apple to match it. They raised their price because Apple had found the solution to Amazon's dumping practice; if Amazon continued dumping, they wouldn't have a price advantage, they'd be forcing undercutting of physical books even more, but not capturing any of the gains, and Apple would still be making money while Amazon would still be losing money on each sale. It would be the publishers eating it. The logical thing for the publishers to do with Amazon would be to raise wholesale prices. If Amazon retaliated by no longer carrying their physical books, the publishers would probably have an anti-trust case they could win.
The publishers can't sue Amazon for selling below wholesale, but Apple could, especially once they're effectively forced to sell below wholesale themselves (and, with Amazon being in the monopoly position, it's Amazon at who's liable, not a competitor who's just trying to be competitive).
What "garbage results"? It's something posted by one of the subjects reflecting on his experience. The other is by one of the researchers, but isn't given as a result of anything, just an example of what they're doing. It's also from a couple months ago, and there's a link to an actual paper as well. You can't complain about garbage results, especially citing specifics that aren't even true ("only two subjects, reading different pieces of code") when there aren't any results in the article.
It might help if you actually read the articles linked to. It's an ongoing study, and results are "very preliminary".
It looks like they have various code samples. The same functionality is coded in different styles. They're studying both how novice vs. experts read code, as well as how coding styles/language features affect comprehension.
I suppose I should look more to see why they selected that, but I'd have preferred to see SRP used. SRP with a zero key (or any other pre-defined key) is essentially DH anyway, and the authentication is built in to the key exchange. It also has the nice feature that one side can't find out the other side's authentication credentials (and hence can't impersonate them).
SRP is typically used in a client-server relationship, but it can be used in a symmetric way as well.
I've never seen a coffee shop that would be confused with an Apple store. You do know that's the idea behind trademarks, right? To protect a brand by not confusing customers as to who they're doing business with, who made a product, etc?
You can have a restaurant with the letter M in it; just don't make it look too much like the Golden Arches and you won't have a problem with McDonalds.
He's just commenting on the math, 5 failures (delivering spam) out of 1000 is 99.50% success (of stopping spam), not 99.95% as was stated in the post he was replying to.
IF you make the source available to someone who downloads it (after paying for it), then you don't need to make the 3(b) written offer, and thus aren't required to provide a copy to anyone. v3 6(d) is very clear on how that works, v2 3(a) is less clear, but "send me e-mail and I'll send you a link to get a copy of the source" is probably not going to satisfy the "accompany" requirement of v2 3(a) and definitely doesn't satisfy the requirements of v3 6(d).
Only if the source was available for download, for no extra charge, AT THE TIME THE BINARY WAS DOWNLOADED. That means without contacting anyone - the method of downloading must be clear (either available from the same server, or "equivalent access"). If the person failed to download it at the time he downloaded the binary version, that's ok - no further obligation on the part of the distributor is required, as long as the source code was made available at the same time and for as long as the binary is still available to be downloaded.
If 3(a) is not used (making the software available from the same server counts for "accompany", and under v3 6(d) is made even more clear), then you must use 3(b). You could satisfy 3(b) by offering to make a CD-ROM or USB drive or something and mail it to anyone, for a small charge, while offering a network download to someone who bought the binary, but do you really want to go through that hassle? Note, there is no equivalent for 3(b) under v3 for downloaded binaries.
Under v3, you only have to provide a written offer if you've provided the binary code in a physical format (CD-ROM, embedded firmware) and didn't include the source code in a physical format.
6(a) is when you provide both binary and source code together, both in a physical form.
6(b) is when you provide binary in a physical form, and provide a written offer, either for physical media (for a "reasonable cost"), or for a network download (at no extra cost). That offer is available to ANYONE who possesses the object code, not just people you've distributed the object code to.
6(d) says if you provide a binary download, you MUST provide access to the source code as well (for as long as the binary is available for download).
Under v2, 3(a) becomes 6(a) and 6(d) are basically the same (6(d) provides clarification of what "accompany" means for a download), and 3(b) becomes 6(b), but only for physical copies, not for downloads.
GPLv3 6(b) only applies if you distributed the binaries in a physical form (on physical media or embedded in a physical object, e.g. firmware).
6(d) applies for copies downloaded over a network, and in that case does not offer the option of a "written offer", only equivalent (and for no extra charge) access to the source; it further clarifies that it does not need to be the same server, but that it be clear and obvious where you can obtain the source and that it is available at the time the binary version is downloaded. Take down the binary, you can take down the source. This mode of distribution basically satisfies v2 3(a), the v2 3(b) clause (written offer) is not allowed for network-distributed binaries under v3.
Slashdot Mirror
Most of the catastrophic coverage plans I see in the exchange (for 27 year-old) are in the $90-200 range. If someone "never goes to the doctor, ever", then the deductible doesn't really matter that much.
HDHP is not the same as Catastrophic.
"Marketplace catastrophic plans cover 3 annual primary care visits and preventive services at no cost."
Try "language of life", quite a few hits. It's a fairly common phrase referring to the specific encoding of amino acids into codons,
plus the stop codons. If you didn't recognize the phrase to start with, you probably shouldn't be criticizing it for being dumbed-down.
4 letters (base pairs), "sets of 3 letters called codons". "Although there are 64 ways of combining 4 letters ...", in that context, is clear and correct.
"The machine is big endian machine, but the typed array from Javascript work with little endian. "
I'm already not impressed.
I'm also disappointed that no real effort was made to push for a single-payer system. I don't particularly LIKE what came out of it, but that simply means it needs to be improved, not scrapped. One option would be to add back the "public option" to the exchanges, a Medicare-For-All offering.
If she never goes to the doctor, maybe she should get Catastrophic coverage (if she's under 30), especially if she doesn't qualify for any subsidies (which don't apply to Catastrophic plans; out-of-pocket subsidies only apply to Silver plans).
You can't get any subsidies because you're already covered by an employer plan.
Why are you comparing your costs (after your employer pays most of it) on your current insurance to the full price of a plan on the exchange? You don't need to buy anything on the exchange, you're already covered.
Doing that would be the "spiteful" thing, actually. A static web page on a single server is about as foolproof as you can get, and at least gives you positive feedback that your link isn't dead or bogus. Just hanging for a while, then getting back "server not responding" would be much worse.
All I was saying is that, while you CAN have a different port when you're connecting to a different address/port, there's no need to (when the internal address/port is the same). Since there's no need to, and it's easier to use a single mapping table (mapping internal IP/port to an external port, regardless of what it's connecting to), I'd think that would be the solution most (cheap) routers would use (the kind that also would only have one external IP address).
As I said, I've never actually bothered writing the bit of code to test to see which routers do what in this regard. I'm sort of surprised that no one has ever simply proposed a standard for doing NAT that way, which would allow any router that uses that method to be easy to do a mediated direct connect.
I've never actually looked at the specific mappings a NAT router uses, but I've thought about how to do a connection between two hosts, each behind their own NAT (and yes, I know there are standards and solutions and all, this was just an exercise).
I'd think the obvious solution to how to map port numbers for NAT would be to map each host/port pair to a single random external port, regardless of the address it's sending/receiving to/from. That way you have just one lookup table for the mapping each way. IF the NAT router does that, then all you do is connect to a common server, which notes your external IP address/port and passes that on to the other party (and vice versa). If you then re-use the same port # on the two hosts, it would then map to the same external port number (since it's still active).
This would work for UDP and TCP. You'd still need to get through the firewall if the router is doing stateful blocking (which is easy to get around - there ought to be a connect_to low level call to do that, but easy enough to do a listen/connect on both sides).
Now, I realize that NAT routers could do the mapping in any of a myriad ways, but since most of them are really simple, I'd think most of them would use the really simple and obvious mapping.
If this just happens to be one of the things that is covered by the patents in question, I can say with assurance that it IS obvious; I've never read about how to do it, I've never looked at the patent, but I came up with that years ago after thinking about the problem for a few minutes. I've never tested it to see if it actually works with real equipment (nor, if it does work at all, what range of equipment it would work on).
Also quite a few Lua interpreters, of varying quality.
See Codea, not only is it a full development environment, you can apparently use it to produce a working standalone app. Look at the first item in their forum for a list of apps in the App Store developed with it.
As for calculators, I vastly prefer RPN, and I have no problems finding RPN calculators for iPad, along with unit conversions (including up-to-date currency rates). I need to look up to see if there's an iOS version of the units program, that's still the gold standard for conversion programs (and is still distributed as part of OSX).
User replaceable battery? How? I don't have any real problems with battery life yet, but I'm not aware that it can be replaced when it eventually reaches end of life.
Referring here only to the E-ink versions (Simple Touch and Glow), they did a lot of things right. Organizing your books is the weakest part, the book shelf implementation is really weak. The Kindle Paper White sounds like it's better hardware wise than the Glow, but not by a lot. My main issue with the Glow is the durability of the screen compared to the unlit Simple Touch.
Kobo sounds really good, especially the higher-resolution larger screen E-ink Aura, but all the social media oriented aspects of it are a bit of a turn-off, and it sounds like they have some real design issues with battery life, auto-power-off and sleep behavior. NOOK seems to get this right.
Ability to boot off of the external microSD card is also a big selling point for me on the NOOK. If they come out with (and don't screw up) a new version using the newer screen technology that's in the Aura, I'd buy it first chance I got (probably end up buying two, in fact, and pass on our current NOOKs to family).
I agree. It sounds like the big mistake was combining the Most Favored Nation clause with telling publishers that the agency model wouldn't move forward unless most/all the other publishers agreed.
Perhaps what Apple should have done is just offered the agency model, with the MFN clause, as an option to the publishers, along with a traditional wholesale/retail model. Then they could do a couple things: negotiate with each publisher to lower the wholesale price, perhaps while also selling at a loss, and getting dumping charges brought against Amazon.
Much has been made of how "Amazon had to raise their prices". No, they didn't. They could have continued to offer e-books for $9.99. All the MFN clause said was that then the publishers would have to lower their price through Apple to match it. They raised their price because Apple had found the solution to Amazon's dumping practice; if Amazon continued dumping, they wouldn't have a price advantage, they'd be forcing undercutting of physical books even more, but not capturing any of the gains, and Apple would still be making money while Amazon would still be losing money on each sale. It would be the publishers eating it. The logical thing for the publishers to do with Amazon would be to raise wholesale prices. If Amazon retaliated by no longer carrying their physical books, the publishers would probably have an anti-trust case they could win.
The publishers can't sue Amazon for selling below wholesale, but Apple could, especially once they're effectively forced to sell below wholesale themselves (and, with Amazon being in the monopoly position, it's Amazon at who's liable, not a competitor who's just trying to be competitive).
What "garbage results"? It's something posted by one of the subjects reflecting on his experience. The other is by one of the researchers, but isn't given as a result of anything, just an example of what they're doing. It's also from a couple months ago, and there's a link to an actual paper as well. You can't complain about garbage results, especially citing specifics that aren't even true ("only two subjects, reading different pieces of code") when there aren't any results in the article.
It might help if you actually read the articles linked to. It's an ongoing study, and results are "very preliminary".
It looks like they have various code samples. The same functionality is coded in different styles. They're studying both how novice vs. experts read code, as well as how coding styles/language features affect comprehension.
What makes you think he's sampling 30fps video? There's even a link to the eye-tracking hardware.
http://www.tobii.com/en/eye-tracking-research/global/products/hardware/tobii-tx300-eye-tracker/
It isn't e-ink, but it also isn't an LCD. RTFA.
I suppose I should look more to see why they selected that, but I'd have preferred to see SRP used. SRP with a zero key (or any other pre-defined key) is essentially DH anyway, and the authentication is built in to the key exchange. It also has the nice feature that one side can't find out the other side's authentication credentials (and hence can't impersonate them).
SRP is typically used in a client-server relationship, but it can be used in a symmetric way as well.
I've never seen a coffee shop that would be confused with an Apple store. You do know that's the idea behind trademarks, right? To protect a brand by not confusing customers as to who they're doing business with, who made a product, etc?
You can have a restaurant with the letter M in it; just don't make it look too much like the Golden Arches and you won't have a problem with McDonalds.
He's just commenting on the math, 5 failures (delivering spam) out of 1000 is 99.50% success (of stopping spam), not 99.95% as was stated in the post he was replying to.
IF you make the source available to someone who downloads it (after paying for it), then you don't need to make the 3(b) written offer, and thus aren't required to provide a copy to anyone. v3 6(d) is very clear on how that works, v2 3(a) is less clear, but "send me e-mail and I'll send you a link to get a copy of the source" is probably not going to satisfy the "accompany" requirement of v2 3(a) and definitely doesn't satisfy the requirements of v3 6(d).
The author says he already did send his changes upstream, but upstream appears to be dead.
Only if the source was available for download, for no extra charge, AT THE TIME THE BINARY WAS DOWNLOADED. That means without contacting anyone - the method of downloading must be clear (either available from the same server, or "equivalent access"). If the person failed to download it at the time he downloaded the binary version, that's ok - no further obligation on the part of the distributor is required, as long as the source code was made available at the same time and for as long as the binary is still available to be downloaded.
If 3(a) is not used (making the software available from the same server counts for "accompany", and under v3 6(d) is made even more clear), then you must use 3(b). You could satisfy 3(b) by offering to make a CD-ROM or USB drive or something and mail it to anyone, for a small charge, while offering a network download to someone who bought the binary, but do you really want to go through that hassle? Note, there is no equivalent for 3(b) under v3 for downloaded binaries.
Under v3, you only have to provide a written offer if you've provided the binary code in a physical format (CD-ROM, embedded firmware) and didn't include the source code in a physical format.
6(a) is when you provide both binary and source code together, both in a physical form.
6(b) is when you provide binary in a physical form, and provide a written offer, either for physical media (for a "reasonable cost"), or for a network download (at no extra cost). That offer is available to ANYONE who possesses the object code, not just people you've distributed the object code to.
6(d) says if you provide a binary download, you MUST provide access to the source code as well (for as long as the binary is available for download).
Under v2, 3(a) becomes 6(a) and 6(d) are basically the same (6(d) provides clarification of what "accompany" means for a download), and 3(b) becomes 6(b), but only for physical copies, not for downloads.
GPLv3 6(b) only applies if you distributed the binaries in a physical form (on physical media or embedded in a physical object, e.g. firmware).
6(d) applies for copies downloaded over a network, and in that case does not offer the option of a "written offer", only equivalent (and for no extra charge) access to the source; it further clarifies that it does not need to be the same server, but that it be clear and obvious where you can obtain the source and that it is available at the time the binary version is downloaded. Take down the binary, you can take down the source. This mode of distribution basically satisfies v2 3(a), the v2 3(b) clause (written offer) is not allowed for network-distributed binaries under v3.