Though it may be impractical I can definitely see the appeal of something like this. I'm not a fan of the current gaming model. Games we buy should be something we can own, preserve and control. It would be enticing to have a physical collection of actual, working games and to be able to use them without internet connection, user accounts, EULAs, launchers, stores, etc.
Also, don't forget there are now launchers (you can't run your game yourself, it has to go through us) and EULAs (you can only play what you buy in our terms). Nice times indeed...
In theory these 2 options seem like a sensible way to have a choice. But the average user is not going to own and carry 2 devices. We want to have all we need in a single device, and things like paying with your phone have become way too common by now to not have them.
Then wait until you learn of useful features that existed in Windows 7 and were removed... I'm especially baffled at the worsening of the file copy dialog.
We are also going to need a breakthrough in how batteries are produced and disposed of. Otherwise the environmental impact of the many millions of batteries themselves may prove unsustainable too.
Maybe better disposal practices. Regulations standardizing batteries would also do a lot of good.
But really, we simply need a lot of virgin batteries regardless because we don't have enough. Recycling and disposal will only really take off once the market is mostly saturated (which we don't appear to be anywhere near).
I'd also point out that modern LiPo batteries are 90% recyclable with no special techniques needed. That's because by weight, the batteries are mostly iron and nickel. Recycling them is really as simple as just melting them down. It only gets tricky if you want to collect the lithium, silicon, and other trace materials (and there are already recycling plants that are handling that).
Funny how no one seems to consider the environmental impact of digging up fossil fuels when they discuss solar.
It's similar to how you can identify Real Bird Lovers. They stay silent when they see pictures of oil-covered birds after an Exxon Valdez or a Deepwater Horizon. Show them a windmill and boy do they get passionate about bird safety and welfare.
Not the best choice to begin the title with "some bits" in this context. My mind was trying to understand this sentence in a completely different way...
It is worth mentioning that in the original game you can choose to keep going after you reach 2048. This game had to remove that option to achieve a 64bit state. Still, a clever implementation.
> keep going after you reach 2048. This game had to remove that option to achieve a 64bit state.
Since 15^16 < 2^64, you can still use a 64 bit state to reach 2^15=32768, which does not seem to be reachable in practice (the previous state would fill the whole board!)
I'm not sure how the math works out, but some googling suggests that 32768 is achievable in practice while 65536 and 131072 are theoretically possible but have only been achieved with undos.
You need 16^16 for 32768 because 0 is used to represent an empty tile (2^0 = 1 is not used) which is exactly equal to 2^64.
The state in this implementation also stores a random seed (between 0 and 99, exclusive), so using 16^16 for the state would leave nothing for the random seed.
We keep hearing different variants of "webp should take over because now it has good browser support". But that is not nearly enough for an image format to reach widespread adoption.
People want to be able to open the images anywhere (what about watching photos in a smartTV? or an old tablet? what about digital picture frames?). They want to edit the images in any program (what about this FOSS editor? what about the many people stuck in pre-subscription Photoshop versions?).
They also want to ensure far future access to their precious photos, when formats like JPEG2000 or even WebP might be long gone. I mean, webp was made by Google and we know how many of their heavily promoted creations are dead already...
i don't like working with webp. especially since chrome pushes it on everyting, but googles other tools like slides do not support it. Super annoying, especially since google developed it.
It also doesn't help that most people's experience with webp is force-recompressed versions of images that were originally jpeg. With relatively low quality settings.
I'm not sure people consciously make that association, but you know which association they absolutely do make? The one where google images started using webp at the same time as they were locking it down. At the time, ecosystem support was practically nonexistent, so it functioned as "soft DRM" and among people who know the term "webp" at all that's by far the #1 association.
The explanation for COBOL is not an engineering one, but an economics one: “It’s cheaper to train a programmer to use COBOL than it is to rewrite the codebase in <language>.” (Perhaps LLMs might change the economics here.)
"If it ain't broke, don't fix it" also applies here.
There is also no guarantee that whatever new language you port the COBOL code to won't also be seen as obsolete in a few years. Software developers are a fickle bunch.
Although you can do a bit of Ship-of-Theseus philosophy on those COBOL systems. After every software component has been rewritten multiple times and every hardware has died and subsequently got replaced, all that's left is the decision to stick with COBOL, not the fact that it's a legacy system built in the 60s.
Last I checked you couldn't even upload .webp images to GitHub or Telegram. Well, for GitHub you can cheat by renaming it to .png and GitHub's content detection will make it work regardless, but meh.
> But that is not nearly enough for an image format to reach widespread adoption
I use WEBP extensively but WEBP has a major flaw: it can do both lossy and lossless.
That's the most fucktarded thing to ever do for an image compression format. I don't understand the level of confusion and cluelessness that had to happen for such a dumb choice to have been made.
I've got an entire process around determining and classifying WEBP depending on whether they're lossless or lossy. In the past we had JPG our PNG: life was good. Simple. Easy.
Then dumbfucks decided that it made sense to cram both lossy and lossless under the same umbrella.
> They also want to ensure far future access to their precious photos, when formats like JPEG2000 or even WebP might be long gone.
That however shall never be an issue. You can still open, today, old obscure formats from the DOS days. Even custom ones only use by a very select few software back then.
It's not as if we didn't have emulators, converters, etc. and it's all open source.
Opening old WEBP files in the future shall never ever be a problem.
Determining if it's a lossy or lossless WEBP for non-technical users, however... ; )
That however shall never be an issue. You can still open, today, old obscure formats from the DOS days. Even custom ones only use by a very select few software back then.
Certainly not true.
One example: I have many thousands of photos from my Sony digital camera that cannot be opened by any current operating system without installing third-party software.
I'm lucky that the camera also output JPEG versions as it saved, so I'm able to view the JEPG thumbnails, then drag the Sony version into my photo editor of choice.
> In the past we had JPG our PNG: life was good. Simple. Easy.
Except for if you wanted a compressed image with transparency for the web, in which case you had to sacrifice one of those two things or use a different format besides those two.
> Then dumbfucks decided that it made sense to cram both lossy and lossless under the same umbrella.
> I don't understand the level of confusion and cluelessness that had to happen for such a dumb choice to have been made.
Besides many end users not caring which one it is as long as they recognize the file type and can open it, I found a few interesting reasons for having both in the same format from a simple web search. One was the possibility of having a lossy background layer with a lossless foreground layer (particularly in an animation).
JPEG XL also decided to support either lossless or lossy compression, so it wasn't just WebP that decided it made sense.
It isn't universal, my phone gallery doesn't support webp at all by default and the windows gallery only supports non-animating webp from what I can tell?
To me what cameras support as an output is irrelevant. On a pro camera you generally use the raw files as a default format. What is important is the formats you can export to / manipulate afterwards for publication/exchange.
Always always always -- and it's often multiple problems, where the filesystem preview generators don't support it or don't support it over a network or the social media used by the other person doesn't support it (often egregiously so, where an unrecognized drop bubbles up to browser scope and blasts the page you were on) or there's a weird problem with a site/app that is supposed to support it, such as it turns into a black box.
Support for webp is still so rough that I have to wonder what one's ecosystem must look like for it to be seamless. Maybe if you are a googler and your phone/computer/browser use entirely google software and ditto for your friends and your friends friends and your spouses? Maybe?
To my knowledge, not even every Google product supports it, but I have not verified support myself.
I blame Google for pushing it, but I also blame every third-party product for not supporting it, when it is mostly free to do so (I'm sure all of them internally use libraries to decode images instead of rolling their own code).
I think it works better in a totally open source ecosystem. I can share webp pics to my daughters via xmpp for example regardless if I am on my smartphone (conversations) or desktop (gajim)
JPEG XL is similarly an algorithm that's been published, but Google removed it from their browser and Mozilla followed suit, which effectively killed its usefulness as a web-friendly (and, more generally, usable-anywhere) format.
Fair enough. What I meant by this is that, in the end, most software that decides to add webp support is doing it because of the huge push by Google to do so. But if they suddenly change that push to something else then webp might find itself growing more irrelevant.
WebP is basically a single i-frame from the WebM video codec, which literally was developed by Google to avoid paying license cost for H.264. For which they had great incentive.
WebP is to WebM what HEIC is to HEVC.
You can argue that using free codecs is a collateral benefit here, even though Google did it for selfish reasons. It is not detrimental to the public or the internet.
I don't get why asking for a password multiple times is perceived as more secure. It's the same password. If an attacker was able to find it and input it once, surely they can do it multiple times too...
It's not about asking for the password, it's about expiring sessions frequently. Nobody is going to steal sessions, of course, but the cargo cult security remains.
