Now, a 4 1/3 oz Coke is obviously too small to be worth bothering with. But that's also true of a 6 1/2 oz Coke. These sizes seem more like something you dispense with an eyedropper than something you drink. A normal can is 12 oz! Who'd want to buy a six-ounce beverage?
You can address both problems at once by doubling the price and increasing the volume all the way up to 8.67 oz.
When I was a kid, most sodas had a short can size of 8oz available, good for "lunches" and similar.
Funny story, Coca Cola just announced thin 7.5oz cans last month, to be available in January.
Shrinkflation is often done by phasing out an old size, often by jacking up the price first to aid the sales of the "family size" version on its way out, and then introducing a "New" size that's just a bit smaller.
But even if there had been, an 8oz can is 23% bigger than a 6.5oz bottle. 6.5oz is ludicrously small. How did that become a commercial size in the first place?
As far as I can tell, a juice box today is 6.75oz, but you buy them in bulk and they're not actually large enough to be good for a small child's lunch.
Well sugary beverages are a treat, not exactly something you should be encouraging a child to drink a lot of or drink often. That's why that dumb logan paul lunchables ripoff is awful for coming with that large drink.
But not everybody agrees with that kind of statement so here's a better one: Small soft drink cans are really good for single serve cocktails.
A single "cup" of coffee is also 6oz, so it's not exactly an abnormal drink size.
As a glass bottle is strange though. But it tends to feel more "Premium" to people
Soft drink companies cater to literally everyone. They eagerly want to sell to both my friend who drinks several liters a day and my grandma who treats half a can of coke as a nice treat and people like me who used to like soda but now mostly use it for mixing drinks and the occasional treat. That's why they sell multiple different formulas of "Coke without sugar" and why there's so much diversity in just the "Citrus flavored" sub category. I miss Vault and Sierra Mist.
I think it's a generational thing. I used to mow the lawn for an elderly distant cousin, in the hot Florida summer weather. She would invite me in afterward for a snack and a 6.5oz Coca-Cola. I would guzzle mine in a couple of seconds. She would pour half of hers into a glass, over ice, and put the bottle back into the refrigerator.
Wine glasses have also gotten bigger over the years.
Operating systems are different though, since their whole purpose is to host _other_ applications.
FWIW, MacOS isn't any better or worse for security than any other desktop OS tbh....
I mean, MacOS just had it's "UAC" rollout not that long ago... and not sure about you, but I've encountered many times where someone had to hang up a Zoom or browser call because they updated the app or OS, and had to re-grant screenshare permissions or something. So, not that different. (Pre-"UAC" versions of MacOS didn't do any sandboxing when it came to user files / device access)
Browser extensions also have a relatively robust permissions-based system.
If they wanted to, one would guess that browser-ish local apps based on stuff like Electron/node-webkit could probably figure out some way to limit extension permissions more granularly.
I would have thought, but it has been how many years, and as far as I know, there is still no segregation for VSCode extensions. Microsoft has all the money and if they cannot be bothered, not encouraged that smaller applications will be able to iron out the details.
I think it's just because supply-chain attacks are not common enough / their attack surfaces not large enough to be worth the dev time... yet...
Sneak in a malicious browser extension that breaks the permissions sandbox, and you have hundreds of thousands to millions of users as an attack surface.
Make a malicious VSCode/IDE extension and maybe you hit some hundreds or thousands of devs, a couple of smaller companies, and probably can get on some infosec blogs...
>Make a malicious VSCode/IDE extension and maybe you hit some hundreds or thousands of devs, a couple of smaller companies, and probably can get on some infosec blogs..
Attackers just have to hit one dev with commit rights to an app or library that gets distributed to millions of users. Devs are multipliers.
The time has come. The nx supply chain attack a couple weeks ago literally exfiltrated admin tokens from your local dev machine because the VS code extension for nx always downloaded the latest version of nx from npm. And since nx is a monoreop tool, it’s more applicable to larger projects with more valuable tokens to steal.
The solution at my job is you can only install extensions vetted by IT and updates are significantly delayed. Works well enough but sucks if you want one that isn't available inside the firewall.
>Browser extensions also have a relatively robust permissions-based system.
Yeah and they suck now. We need a better security model where it's still possible to do powerful stuff on the whole machine (it's MY computer after all) without compromises.
>We need a better security model where it's still possible to do powerful stuff on the whole machine
That's not possible. If you can do powerful stuff on the whole machine by definition you have no security. Security is always a question of where you create a perimeter. You can hand someone a well defined box in which they can do what they want, you can give someone broader access with fewer permissions, but whether vertically or horizontally to have security is to exercise control and limit an attack surface.
That's even implicit in the statement that it's YOUR computer. The justification being that there's a dividing line between your computer and other computers. If you'd be part of of a network, that logic ceases to hold. Same when it comes to components on your machine.
There's a chance that they might stall you and never actually pay (or chargeback the invoice).
That way they'll get a free link for at least some amount of time, and if done at massive scales correctly, it could bump some site up the search results for long enough.
The article mentions having the OP send a PayPal invoice...
Pretty sure the other side is not gonna pay it unless you follow through (i.e. they could always charge it back and claim you never delivered the invoiced service, heck they might do that even if you put up the link!)
I'd say China doesn't have particularly tight_er_ information control than other places, they're using the same tools everyone else is using (keyword/hashtag bans, algorithmic content demotion, "shadowbans" of responses, and outright content removal etc.)...
It's mainly just that there's more politically motivated manipulation... versus in the west where those tools would be used on things like copyright infringement, pornography, and misinformation etc.
Yeah, one option is to use a different content-type for your json-patch values and basically extend JSON Patch[1] to use JSON Path[2] instead of JSON Pointer[3].
Right to repair just means for those that do want to repair it, they can without any undue burden.
If you don't want to repair it, nobody is forcing you to! Just throw it away like you would have done anyways.
The point of right to repair is that there is a non-zero amount of people who want to repair stuff and it shouldn't cost the people who don't anything extra... It's a "right" not an "obligation"...
> But if you go to a shitty concert, you don't get your money back. If you buy a shitty album, you can't get your money back. And you can't get the band to "make it better" for you.
The difference is whether "shitty" is subjective or actually defective.
Like, if you don't like the music, that's on you, someone else might like it.
And, I've certainly been to concerts / movies / events where there have been "experience-breaking" technical difficulties and they've (partially or fully) refunded the tickets.
The provider could reject further access to them (reads / writes) once the limit is reached. The cost of actually keeping objects as "cold" storage has a natural cap per billing cycle since those are billed based on time.
> The Coca-Cola Company sought ways to increase the five cent price, even approaching the U.S. Treasury Department in 1953 to ask that they mint a 7.5 cent coin. [https://en.wikipedia.org/wiki/Fixed_price_of_Coca-Cola_from_...]