No, and it's really obnoxious, because there are thresholds where content doesn't have to be listed. For example, a package of tic-tacs will say that it has 0g sugar per serving (a 'serving' being one tic-tac), but the whole (small) package will have something like 20g of sugar.
This is one thing I actually think America does right. I'm the type of person to eat a single tic-tac, but even if I acknowledge that there are failures, it's far easier for me to get a rough sense as to how bad eating something is if it lists it's actual content. Ideally there would be both, but having to do 0.85 * 260 just to get the calorie count for this is just annoying.
I do think the design of the labels is completely ridiculous, though. Sugar, trans fats, and caloric count should be made much more prominent and put in red so that uninformed people understand that these are the primary causes of sickness in America.
That's more-or-less what Sainsbury's (in the UK) did with their products.
Most things must show the amount per serving and the amount per 100g (in common across the EU), but they also show a chart with green/orange/red based on a typical serving size.
Obviously, it's easier to compare if they are all relative to 100g, but arguably per-serving is more useful when making eating decisions. When I'm buying a food, I'm not trying to do science; I'm trying to figure out how much of a particular nutrient I'm personally going to get when I eat that item.
For example, if I have soup, there's no way I'll have as little as 100g of it. If I have tea, there's no way I'm going to have as much as 100g of tea leaves. The mass of a serving could be 1 or even 2 orders of magnitude different depending on the type of food.
Per-serving isn't standard between items though. The FDA requirements are broad enough that companies can make up their own serving sizes, and one company could consider a 12oz can one serving, and the other two.
If the two-serving brand is also advertised as low sodium and consumers don't notice that the serving size is half as big, that's gonna seem to be much lower sodium than it really is.
It can certainly go either way, but space and simplicity would be the arguments against including both. On a small label, you might need to use a smaller font. Even if you have enough space, a more minimalist approach can be quicker to read (provided that it contains the information you actually want).
What drives me nuts is that the Nutrition Information has metric units but the front of the package may not (e.g. "One Quart (32 oz)" but no liter equivalent printed).
Worse is that many products have bogus information. I'm not talking just about the inexactness of the methods, but in many cases the macronutrient math doesn't add up.
Total calories should be about (protein + carb)x4 + (fat)x9. Too often, it isn't close. I was comparing two versions within a product line yesterday (chili with beans vs without beans), and the calorie count for one mismatched the macronutrient breakdown by almost 10%.
If you think that's bad, I encountered a package of tofu recently which stated "Serving Size: 1/4 package; Servings per Package: 8"! Things like that really make you wonder about the reliability of the rest of the information on the label...
Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments.
So an interpretation to support an ideal despite the optional nature of payment channels, got it. I had ctrl+f "payment channels" and got zero results.
Payment channels, as described by the lightning network, are optional.
The mempool on both chains are practically empty and both chains function the same, until the mempool is full.
One chain will allow for optionally greater throughput via payment channels and possible a block size expansion.
One chain will allow for block propagation upwards of 8 megabytes.
Neither relies exclusively on third parties. The first mentioned chain has an optional ironic future where everyone operates a payment channel and eventually consolidates into one payment channel provider, I guess.
Both chains have other "threats" towards centralization.
Apple has shown the willingness to compromise to access the Chinese market, so there's absolutely no reason to believe that they wouldn't or haven't bow to their other demands, including the weakening of their device security.
> If I were Chinese I'd be feeling pretty damn patronized if someone told me they were taking my iPhone away and I should be happy about it.
No. You just have to reform your government or leave your country, then you can have it back. I know that this isn't likely, but putting more pressure on the CCP is exactly what Apple could be doing here.
(Edit: The sibling comment thread already goes into detail on this idea.)
You're right that a clear dividing line is needed here. To be fair to Apple, though, they have given this official statement on the matter:
"As we have stated before, Apple has never worked with any government agency from any country to create a backdoor in any of our products or services. We have also never allowed access to our servers. And we never will. It’s something we feel very strongly about."
It is perhaps notable that Apple is not trying to hide or deny this removal of VPN apps (not that they could really do that effectively). As long as Apple is open about its policies, then we have our clear dividing line (and it would be unreasonable to expect Apple to think of every conceivable future technological/policy question in advance).
Still, this is assuming that we can trust Apple to admit its policies, and moreover to consistently follow them, which even governments seem to have trouble doing. It would be nice to instead have technological ecosystems where end users and citizens didn't have to trust the policies and promises of powerful organisations.
> Apple has never worked with any government agency from any country to create a backdoor in any of our products or services.
Is there any reason for them to not automatically generalize this to "...with any entity from any country"? I'm wondering about a case where a government agency hides behind some other veil and makes Apple insert some backdoor.
Stupid question: can the glue code not be licensed under both GPL and CCDL?
Clearly ZFS is not a derivative work of Linux and Linux is not a derivative work of ZFS. Only the glue code is in violation (because it derives from both).
I'm not sure this is true. It's certainly possible to construct an API/ABI such that one could build the glue, or even dispense with it, without having to use any part of ZFS or the kernel to build the other or the glue. I'm not saying that's been done. But it could be done. Indeed, that's what FUSE is, for example, and that's what NDIS does, for another.
To determine whether there is glue here that violates the GPL would require looking at the particulars. Said glue might be licensed under the GPL, and might export the sorts of interfaces that Illumos does, thus allowing the ZFS module to link without reference to either the glue or the kernel! Then how could such glue be said to violate the GPL? It couldn't! Nor could ZFS be said to be violating the GPL in that case.
I don't think you can avoid an escape hatch for the GPL in the kernel without disallowing dynamic loading or modifying the GPL to have harsher terms. But recall that the GPL, and/or much software distributed under the GPL, is designed to have escape hatches: so you can run proprietary software using standard interfaces, for example (i.e., user-land code is not required to be GPLed just because it runs on a GPLed kernel, though a kernel could require it, it's just that _Linux_ doesn't).
It seems here you can't have your cake and eat it too.
That some people are too vain to adopt is not a good enough justification. It is a foundational point of ethics that medical experimentation must be voluntary.
Market capitalization general corresponds with the amount of debt a company is able to take on, and the creation of debt literally is the creation of money.
> As I understand it, bitcoin doesn't track coins so much as it tracks the funds associated with account numbers.
It's actually the opposite. The blockchain does track coins, but not accounts or account numbers. Rather, each transaction involves "scripts" which specify some conditions with which coins can be used as inputs to another transaction.
In a normal transaction, one key can spend the coins, but e.g. it is possible to send coins to a script that is impossible to satisfy, therefore the coins are unspendable, yet don't exist in an 'account' at all.
Decaying in more than one way. The JS files on milliondollarhomepage.com start with:
/*
FILE ARCHIVED ON 5:47:20 Aug 6, 2015 AND RETRIEVED FROM THE
INTERNET ARCHIVE ON 20:45:17 Aug 24, 2015.
JAVASCRIPT APPENDED BY WAYBACK MACHINE, COPYRIGHT INTERNET ARCHIVE.
ALL OTHER CONTENT MAY ALSO BE PROTECTED BY COPYRIGHT (17 U.S.C.
SECTION 108(a)(3)).
*/
Either that, or the homepage owner doesn't want to pay the hosting (bandwidth) costs, so he/she just references the Way Back machine. This is kinda brilliant.
returns an HTTP 200 (not a 301/302). Additionally, the comment says:
/*
FILE ARCHIVED ON 5:47:20 Aug 6, 2015 AND RETRIEVED FROM THE
INTERNET ARCHIVE ON 20:45:19 Aug 24, 2015.
JAVASCRIPT APPENDED BY WAYBACK MACHINE, COPYRIGHT INTERNET ARCHIVE.
ALL OTHER CONTENT MAY ALSO BE PROTECTED BY COPYRIGHT (17 U.S.C.
SECTION 108(a)(3)).
*/
Note the dates. It was archived on Aug 6, 2015 and retrieved just 18 days later on Aug 24, 2015. Given it's 2017, there's no way this file is being served directly from archive.org's servers.
The '/index_files/' bit seems to imply someone went to the internet archive, pulled up milliondollarhomepage, and then in a Browser, did 'Save As Webpage Complete' which saves the main page (in this case index.htm) and all its assets in a sub folder called 'index_files'.
They then just copied it all as-is back into some web hosting.
