"fine" is a very accurate word to describe Tizen. It's slow and really hard to find things sometimes (why do TVs not have a simple "input switch" button any more?), but ultimately it gets the job done.
You can make Tizen much faster by manually uninstalling the Samsung TV Plus app. It runs in the background constantly. "Much faster" is still slow overall, unfortunately.
If you constantly pawn a task or cognitive load onto someone else (AI or not), you'll eventually get worse and worse at that particular type of thinking. Your overall mind doesn't necessarily get weaker, but you definitely start to get worse at anything you don't regularly practice.
I am a bit confused and very curious what purpose this site is trying to serve. They seem to have many articles all talking about the same concept which I think could be summarized as: "code is fungible". That is to say, the tests, specifications, and other supporting documentation are the truly important pieces of a system. The code part is easily replaceable. Every article on the site is about that concept in some way.
Human language is imprecise and it seems to be a common thought on HN that it is impossible to clearly and completely define the requirements of a sufficiently complex system of software without, well... writing the software. I just don't see a scenario where The Phoenix Architecture would actually make sense.
> The deletion test is not a recommendation. It’s a diagnostic.
> That’s not robustness. It’s entanglement.
> This isn’t a tooling fad. It’s an economic shift.
I have a strong feeling this article would survive regeneration well.
In 2020 Netflix claimed they would start to automatically cancel inactive accounts [1], but the post has since disappeared. I also remember Microsoft saying the same thing about Xbox Game Pass but have not searched for their statement.
As someone with no real-world petrochemistry experience, but much gaming experience, I was very surprised how familiar the crude oil processing diagram looks. Factorio and GregTech are two prime examples of fairly realistic oil processing lines (probably as accurate as any game would reasonably try to be).
I'm trying to understand what you mean by this. Are you saying they're "bad" in terms of resolution, or artistic value, or something else? They seem good enough (far from "bad") by any definition I can think of.
`9↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑9` seems like a reasonable guess (barring encoding cheats/trickery like @masfuerte commented!)
Edit: I've misread the above comment and my number is is 64 bytes (significantly more than 64 bits. The largest 64 bit number through my approach would be `9↑↑↑↑↑↑9`, which is significantly smaller.
Fun to see you here - I discovered this game through your videos! I think despite the lack of raw "content", I got a LOT of playtime out of this game by trying to push higher on the leaderboards.
I think it's more appropriate to say TOTP /is (nearly)/ phishing-proof if you use a password manager integrated with the browser (not that it /doesn't need to be/ phishing-proof)
> I still don't understand the arguments about a future date requiring a timezone.
It's not that a future date requires a time zone, you are right that can be 100% represented with a fixed timestamp. But there is the extreme case that time zone rules may change from the time you schedule the event to the time it happens, and in that case your event is now at the wrong time.
Consider the case where you have a weekly meeting at 9:00 AM on Tuesdays in an America/Chicago office. You could surely calculate the next N weeks of meetings and save them as UTC timestamps, taking into account that we shift into daylight savings time at some point, so you end up with a nice list of timestamps at 9:00 local time. But if the time zone rules change at any point (say, Chicago decides not to observe daylight savings time any more), now all of your meetings are an hour off.
If you had saved the meetings in a more verbose but true-to-intent format that properly captures "Every Tuesday at 9:00 AM America/Chicago", then at the time those rules changed you would either automatically have updated meeting timestamps, or some consolidation process could go and update the meeting times.
Even without sweeping changes like that, we still have unscheduled leap seconds, minutes, etc. every once in a while, which will also mess up your timestamps. I'm actually excited to see the day my calendar somehow ends up with a meeting at exactly 9:00:01.