It’s cool, it’s probably just self extracting. For convenience!
Just chilling
It’s cool, it’s probably just self extracting. For convenience!
You’re approaching the limit of possible upvotes on Lemmy pretty soon here.
I usually think TurboTax is tracking me and selling my data to Google and others.
Linux ISOs obviously
That’s exactly what Half Life 3 will be.
LMAO we really have Lemmy cliques?
Sandpaper remote, coming right up!
It’ll probably be stored in something like a TPM, whose primary purpose is to make intact extraction of the keys difficult or impossible. A few keys might become compromised but in this scenario (unlike DRM decryption) it’s easy to ignore those keys. There’s always the chance an exploit becomes available and is more widely used, though, in which case it would definitely be less valuable.
I can get behind his Twitter handle.
Plus you have plenty of time to tumble once or twice while your large codebase compiles.
Is there a language that anyone would say really does fare well for continued development or is it just that few people enjoy maintaining code? I’ve maintained some pretty old Go programs I wrote and didn’t mind it at all. I’ve inherited some brand new ones and wanted to rage quit immediately. I’ve also hated my own code too, so it’s not just whether or not I wrote it.
I have found maintainability is vastly more about the abstractions and architecture (modules and cohesive design etc) chosen than it is about the language.
It’s cool, you just have to drop a grand every year or two to enjoy that gorgeous screen. Think of it like a subscription to a 15% prettier screen for only 5x the price over 10 years.
The real primary benefit of storing your relationships in a separate place is that it becomes a point of entry for scans or alterations instead of scanning all entries of one of the larger entity types. For example, “how many users have favorited movie X” is a query on one smaller table (and likely much better optimized on modern processor architectures) vs across all favorites of all users. And “movie x2 is deleted so let’s remove all references to it” is again a single table to alter.
Another benefit regardless of language is normalization. You can keep your entities distinct, and can operate on only one of either. This matters a lot more the more relationships you have between instances of both entities. You could get away with your json array containing IDs of movies rather than storing the joins separately, but that still loses for efficiency when compared to a third relationship table.
The biggest win for design is normalization. Store entities separately and updates or scans will require significantly less rewriting. And there are degrees of it, each with benefits and trade-offs.
The other related advantage is being able to update data about a given B once, instead of everywhere it occurs as a child in A.
Helldivers 2 CEO Breaks Ground with Innovative Metaphor of “Changing the Engines While the Plane is in Flight!”
Plus how many hours of fun is that dirt going to give you? Probably not 80!
They turned Clippy into a game?
Hey there! Looks like you’re trying to release some dopamine!
Merge takes two commits and smooshes them together at their current state, and may require one commit to reconcile changes. Rebase takes a whole branch and moves it, as if you started working on it from a more recent base commit, and will ask you to reconcile changes as it replays history.
For corporations tho. It’s much easier to prove for these schmucks legally required to buy our services.
I wish this wasn’t so true.