😬 not proper-back yet (just a brief lull), but thanks haha

The agency had learned about a semitrailer coming across the Mexican border, and agents tracked the drugs to the farmers market, said DEA Special Agent in Charge Robert Murphy. The drugs were found inside the truck, he said.

“This was contained in a cover load of celery,”

So unfortunately not inside the celery itself, which would of course be significantly more fun :(

Region code 0 ("Worldwide") discs work in all regions: https://en.wikipedia.org/wiki/DVD_region_code

Rise of Nations (originally released back in 2003) had/has some interesting ideas to reduce some of the busywork:

• Worker units will automatically try to gather/build nearby after a short (configurable) delay if they're not doing anything.
• Cities (the main worker-producing structure) has a rally point option that's essentially "all nearby empty resource gathering", so you can queue a dozen workers and they'll distribute themselves as they're created.
• Production buildings can be set to loop over their current queue, letting you build continually without intervention as long as you maintain enough resources each time the queue "restocks".
• Units that engage in combat without being given an explicit target will try (with modest success) to aim for nearby units which they counter.

For the most part, none of the implemented options are strictly better than micromanaging them yourself:

• You will always spend less time idling workers if you micromanage them yourself.
• The auto-rally-point doesn't always prioritize the resources that you would if you did it yourself.
• Queueing additional units is slightly less resource-efficient than only building one thing at a time.
• Total DPS is higher if you manually micro effectively.

But the options are there when you need them, which I think is a a nice design. It doesn't completely remove best-in-class players being rewarded for their speed as a player, but does raise the "speed floor", allowing slower players to get more bang for their buck APM-wise, and compete a bit more on the strategy/tactics side of the game instead.

I'm not sure it qualifies as "reverse review bombing" if the recent review +/- percentage matches the all-time percentage. There's just more reviews because of the shutdown, the ratio of positive vs negative hasn't meaningfully changed (97% positive overall, 97% positive recently).

Actual summary:

• The article's focus is: lump sum payment vs regular payment.
• Program had three groups: $20/month for 2 years, $500 lump sum, $20/month for 12 years.
• Lump sum allowed people to invest (e.g., to start a business) in a way that monthly payments didn't.
• Monthly recipients often pooled funds in rotating savings and credit associations (ROSCAs) to provide a lump-sum-like investment ability.
• Monthly recipients were "generally happier and reported better mental health" than lump sum recipients. Articles quotes speculation of cause to be stress related to investment vs the stability from having monthly payment.
• "The researchers found no evidence that any of the payments discouraged work or increased purchases of alcohol".

While you're free to circlejerk about how the article shows how great UBI is, that's not really what it talks about.

They were careful with how they phrased it, leaving the possibility of a refresh without a performance uplift still on the table (as speculated by media). It looks like the OLED model's core performance will be only marginally better due to faster RAM, but that the APU itself is the same thing with a process node shrink (which improves efficiency a little).

See also: PCGamer article about an OLED version. They didn't say "no", and (just like with the previously linked article), media again speculated about a refresh happening.

It looks like they were consistent with what they were talking about with how it wasn't simple to just drop in a new screen and leave everything else as-is, and used that opportunity to upgrade basically everything a little bit while they were tinkering with the screen upgrade.

Unless you're also throwing money at YouTube premium (etc), isn't this by definition unsustainable to do? So it's not really a viable long-term strategy either.

Like don't get me wrong, I don't want all the tracking and stuff either, but somebody has to pay those server bills. If it's not happening through straight cash then it's going to be through increasingly aggressive monetization and cost-cutting strategies.

Yes, though just nitro basic. Discord doesn't show ads and claims to not sell my data. While I can afford to do so, I'd much rather pay a few bucks a month to keep it that way.

The number of people in this thread aggressively against a free-to-use service having any kind of way to pay employees and server bills makes me fucking depressed, and helps to explain why most free services I enjoy never seem to stay afloat with just an optional payment-based membership thing.

Edit: To people suggesting less corporate-based (whether FOSS or not) alternatives, that's totally cool! Just remember that the people behind these projects need some way to pay the bills the same way the corporate ones do, so I encourage you to contribute to them, whether that's through e.g., code improvements (which doesn't pay bills but is still helpful!) or plain old donations.

UPDATE: the shutdown has been (for now) retracted.

The admin (jerry) has switched from kbin to a fork called mbin that has apparently been able to integrate changes faster than the base kbin project. Jerry seems satisfied with the number of issues fixed in the fork (for now), so has retracted the shutdown announcement (for now).

FEDIA.IO update!!!

After I made the announcement about shutting down fedia.io, someone pointed out that Melroy, a very active developer on kbin, forked kbin to mbin. I just migrated to mbin and so far it seems to have resolved all the problems I've seen. It's likely too early to tell, but I think that Melroy is VERY responsive and helpful, so I am retracting my shutdown announcement. And that makes me very happy.

https://infosec.exchange/@jerry/111235153655966812

Followup: https://fedia.io/m/fedia/t/350673 tl;dr retraction has become more concrete. No need for the "for now" qualifier anymore.

It depends a lot on what's being encoded, which is also why different people (who've actually tested it with some sample images) give slightly different answers. On "average" photos, there's broadly agreement that WebP and MozJpeg are close. Some will say WebP is a little better, some will say they're even, some will say MozJpeg is still a little better. Seems to mostly come down to the samples tested, what metric is used for performance, etc.

I (re)compress a lot of digital art, and WebP does really well most of the time there. Its compression artifacts are (subjectively) less perceptible at the level of quality I compress at (fairly high quality settings), and it can typically achieve slightly-moderately better compression than MozJpeg in doing so as well. Based on my results, it seems to come down to being able to optimize for low-complexity areas of the image much more efficiently, such as a flatly/ evenly shaded area (which doesn't happen in a photo).

One thing WebP really struggles with by comparison is the opposite: grainy or noisy images, which I believe is a big factor in why different sets of images seems to produce different results favoring either WebP or JPEG. Take this (PNG) digital artwork as an extreme example: https://www.pixiv.net/en/artworks/111638638

• Original: 6,080,273 bytes
• MozJpeg (Q88, 4:2:0): 438,687 bytes
• WebP (Picture preset, Q90): 595,634 bytes

This image has had a lot of grain added to it, and so both encoders end up with a much higher file size than typical for digital artwork at this resolution. But if I put a light denoiser on there to reduce the grain, look at how the two encoders scale:

• MozJpeg (light denoise, Q88, 4:2:0): 394,491 bytes (~10% reduction)
• WebP (light denoise, Picture preset, Q90): 424,612 bytes (~29% reduction)

Subjectively I have a preference for the visual tradeoffs on the WebP version of this image. I think the minor loss of details (e.g., in her eyes) is less noticeable than the JPEG version's worse preservation of the grain and more obvious "JPEG compression" artifacts around the edges of things (e.g., the strand of hair on her cheek).

And you might say "fair enough it's the bigger image", but now let's take more typical digital art that hasn't been doused in artificial grain (and was uploaded as a PNG): https://www.pixiv.net/en/artworks/112049434

• Original: 2,184,811 bytes
• MozJpeg (Q88, 4:2:0): 200,933 bytes
• WebP (Picture preset, Q90): 164,078 bytes

Subjectively I once again prefer the tradeoffs made by WebP. Its most obvious downside in this sample is ~~on the small red-tinted particles coming off of the sparkler being less defined,~~ [see second edit notes] probably the slightly blockier background gradient, but I find this to be less problematic than e.g., the fuzz around all of the shooting star trails.. and all of the aforementioned particles.

Across dozens of digital art samples I tested on, this paradigm of "WebP outperforms for non-grainy images, but does comparable or worse for grainy images" has held up. So yeah, depends on what you're trying to compress! I imagine grain/noise and image complexity would scale in a similar way for photos, hence some of (much of?) the variance in people's results when comparing the two formats with photos.

Edit: just to showcase the other end of the spectrum, namely no-grain, low complexity images, here's a good example that isn't so undetailed that it might feel contrived (the lines are still using textured [digital] brushes): https://www.pixiv.net/en/artworks/112404351

• Original: 1,804,869 bytes
• MozJpeg (Q88, 4:2:0): 339,182 bytes
• WebP (Picture preset, Q90): 244,224 bytes

I quite strongly prefer the WebP version here, even though the JPEG is 39% larger!

Edit2: I've corrected the example with the sparkler - I wrote the crossed out section from memory from when I did this comparison for my own purposes, but when I was doing that I was also testing MozJpeg without chroma subsampling (4:4:4 - better color detail). With chroma subsampling set to 4:2:0, improved definition of the sparkler particles doesn't really apply anymore and is certainly no longer the "most obvious" difference to the WebP image!

The advertised “regular device upgrades” will never happen for anyone as part of Pixel Pass, even customers who battled Google’s servers to order a Pixel 6 the moment they became available (it’s me; I’m one of those people) because there’s still more than a month to go before the very first customers in would cross the two-year mark and be eligible to upgrade.

So a core part of the premise of Pixel Pass (device upgrades) is being lost, even to existing Pixel Pass users.

Original marketing from 2021:

Pixel Pass brings together the latest Pixel phone with Google’s best mobile services, device protection and regular device upgrades — all in one easy subscription. (emphasis added)