Some backstory - I like gaming quite a bit - but more of a personal archivalist. I have basically all games I've ever played on physical media and try to keep someway to play them offline - just jailbroke my 360 to be able to play games from HDD incase the DVD drive broke. Anyway...
I saw the no DVD and was initially devastated. I'm in two minds - I saw one post that basically said "it won't contain a DVD at launch".. if I read between the lines, though I'm not sure I see the value incentive for Rockstar, but...
If they hypothetically launched with physical boxes with digital download codes, okay... This would definitely be in the name of re-sellers (as they've stated). But this is the same as piracy, which has always been, not that "we need to stop people from pirating our games for eternity" but "we need to stop people pirates our game for X months after launch", which makes sense (the piracy party).
So, I'm wondering, if they actually begin releasing physical disks (offline, re-sellable, usable in 20 years), say, 6-12 months after releasing the game.. would that work? I mean, for me, assuming it's the equal block-buster to the franchise I adore (in a varying sense), then I might not mind too much to pick up a copy after 6-12 months (I don't care about bleeding edge).. but... would this work? If we assume the first 12M of buyers can't resell, would the people who buy the game after 12M actually bring a great number to the second hand market.. perhaps not?
I really have the idea of having games that I love in physical form that I know it can't be taken away.. similar to reading a book that you end up reading and know you want to come back to anytime in the future.. and this would _suck_ if I couldn't get a copy (and I assume all PC versions would be full of online-only DRM stuff anyway).
The highest capacity blurays available are 128GB and there's a good chance the game is larger than that, so it'd need to be a multi-disc installer.
I used to think physical media was great, but optical discs do have a finite shelf life. DRM-free is the important part, so you can make your own backups (like you're doing with your 360).
Physical media doesn't work when modern games are 100GB or more.
And to answer your question, most consumers don't care. The convenience of being able to buy with a few clicks and download immediately without going to a store or waiting for the mail is far more beneficial to most people than being able to locally archive or replay in 20 years.
PS5 and XBox support Blu-ray discs with capacities up to 100 GB. Both GTA V and GTA IV used multiple discs (there was an installation disc and a play disc). Heck the PC version of GTA V required 7 DVDs:
The bigger difficulty comes from the increasing complexity of games (feature wise) and their release state.
It's effectively impossible to release a "gold version" game to the quality standards of ~1990 physical media, in 2026.
The surface area for potential gameplay bugs is too large: it'd take another decade of QA polish.
So even if you have physical media for the release day version of a game, what can you do with that? Play a buggy version?
To GP's point about post-release physical editions, it makes more sense to sell something later that rolls up the most critical post-release patches and content.
This doesn't track with actual game releases, on the contrary it tends to be smaller/simpler games that release exclusively digitally and the big triple A games continue to release physical discs.
As far as bugs go, the solution for this has been and continues to be that after you install the game from the disc, you download a patch to update it. It's been this way for almost 20 years now (XBox 360 and PS3 both launched with explicit support for this).
> big triple A games continue to release physical discs.
Technically correct, but not really correct. It's hard to think of a game in the last decade where I've inserted a physical disk an been able to play without having to download a giant update first. Sometimes literally impossible - the installer disk isn't a complete game until you download an update
If the game they release on a physical disk is unplayably buggy, do they owe you a refund? Even if online updates make it perfect? They can't require that you play it online unless its not even available physically.
> Physical media doesn't work when modern games are 100GB or more.
This is a totally fair point and literally something I haven't even considered.
> most consumers don't care
I know.. I know.. I mostly commented because the linked article _does_ speak about it and that it implied people weren't happy (mostly for re-sell not for archival purposes). But, yes, I get that
I guess my point is.. if they were really to wait for X months and then start to release physical media (again, I can't see the financial incentive for them to do it), but it would really put a big split between: 1) people that buy that the game and simply want to re-sell it and 2) people that want to buy the game to "last forever" (like myself).
Because most of the people in 1) are _likely_ to be the people wanting to buy at launch, play it and move on, the second are _probably_ more willing to wait (or even (probably) wait and buy a second copy later).
I've spent quite a long time looking at artifact storage, both for work and for personal use and this project literally scratches that itch.
So featureful (assuming they're not placeholders ;) ) and yes, Claude Code, but still - the proof will be in whether it works (and how clean the codebase feels - you're making it sound promising :D ).
I agree this doens't seem too ambiguous - it's "you may do this.." and they said "or we may do the reverse". If I say you're could prefix something.. the alternative isn't that you can suffix it.
But also.. the programmers working on the software running one of the most important (end-user) DNS servers in the world:
1. Changes logic in how CNAME responses are formed
2. I assume some tests at least broke that meant they needed to be "fixed up" (y'know - "when a CNAME is queried, I expect this response")
3. No one saw these changes in test behavoir and thought "I wonder if this order is important". Or "We should research more into this", Or "Are other DNS servers changing order", Or "This should be flagged for a very gradual release".
4. Ends up in test environment for, what, a month.. nothing using getaddrinfo from glibc is being used to test this environment or anyone noticed that it was broken
Cloudflare seem to be getting into thr swing of breaking things and then being transparent. But this really reads as a fun "did you know", not a "we broke things again - please still use us".
There's no real RCA except to blame an RFC - but honestly, for a large-scale operation like there's this seems very big to slip through the cracks.
I would make a joke about South Park's oil "I'm sorry".. but they don't even seem to be
> 4. Ends up in test environment for, what, a month.. nothing using getaddrinfo from glibc is being used to test this environment or anyone noticed that it was broken
"Testing environment" sounds to me like a real network real user devices are used with (like the network used inside CloudFlare offices). That's what I would do if I was developing a DNS server anyway, other than unit tests (which obviously wouldn't catch this unless they were explicitly written for this case) and maybe integration/end-to-end tests, which might be running in Alpine Linux containers and as such using musl. If that's indeed the case, I can easily imagine how noone noticed anything was broken. First look at this line:
> Most DNS clients don’t have this issue. For example, systemd-resolved first parses the records into an ordered set:
Now think about what real end user devices are using: Windows/macOS/iOS obviously aren't using glibc and Android also has its own C library even though it's Linux-based, and they all probably fall under the "Most DNS clients don't have this issue.".
That leaves GNU/Linux, where we could reasonably expect most software to use glibc for resolving queries, so presumably anyone using Linux on their laptop would catch this right? Except most distributions started using systemd-resolved (most notable exception is Debian, but not many people use that on desktops/laptops), which is a locally-cached recursive DNS server, and as such acts as a middleman between glibc software and the network configured DNS server, so it would resolve 1.1.1.1 queries correctly, and then return the results from its cache ordered by its own ordering algorithm.
For the output of Cloudflare’s DNS server, which serves a huge chunk of the Internet, they absolutely should have a comprehensive byte-by-byte test suite, especially for one of the most common query/result patterns.
> Ends up in test environment for, what, a month.. nothing using getaddrinfo from glibc is being used to test this environment or anyone noticed that it was broken
This is the part that is shocking to me. How is getaddrinfo not called in any unit or system tests?
I would hazard a guess that their test environment have both the systemd variant and the Unbound variants (Unbound technically does not arrange them, but instead reconstructs it according to RFC "CNAME restart" logic because it is a recursive resolver in itself), but not just plain directly-piped resolv.conf (Presumably because who would run that in this day and age. This is sadly just a half-joke, because only a few people would fall on this category.)
We used to say at work that the best way to get promoted was to be the programmer that introduced the bug into production and then fix it. Crazy if true here...
What you're suggesting seems like a spectacular leap.
I do not think it is very likely that the unnamed employee at Cloudflare that was micro-optimising code in the DNS resolver is also the author of this RFC, Joe Abley (the current Director of Engineering at the company, and formerly Director of DNS Operations at ICANN).
> I assume some tests at least broke that meant they needed to be "fixed up"
OP said:
"However, we did not have any tests asserting the behavior remains consistent due to the ambiguous language in the RFC."
One could guess it's something like -- back when we wrote the tests, years ago, whoever did it missed that this was required, not helped by the fact that the spec proceeded RFC 2119 standardizing the all-caps "MUST" "SHOULD" etc language, which would have helped us translsate specs to tests more completely.
Oh, they explain, if I understand right, they did the output change intentionally, for performance reasons. Based on the inaccurate assumption that order did not matter in DNS responses -- becuase there are OTHER aspects of DNS responses in which, by spec, order does not matter, and because there were no tests saying order mattered for this component.
> "The order of RRs in a set is not significant, and need not be preserved by name servers, resolvers, or other parts of the DNS." [from RFC]
> However, RFC 1034 doesn’t clearly specify how message sections relate to RRsets.
The developer(s) was assuming order didn't matter in general, cause the RFC said it didn't for one aspect, and intentionally made a change to order for performance reasons. But it turned out that change did matter.
Mistakes of this kind seem unavoidable, this one doesn't necessary say to me the developers made a mistake i never could or something.
I think the real conclusion is they probably need tests using actual live network stacks with common components, and why didn't they have those? Not just unit tests or with mocks, but tests that would have actually used real getaddrinfo function in glibc and shown it failing?
Even if there weren't tests for the return order, I would have bet that there were tests of backbone resolvers like getaddrinfo. Is it really possible that the first time anyone noticed that that crashed, or that ciscos bootlooped, was on a live query?
I did music production at the same time as heavily using SVN and starting to use Git - I didn't cross this over at the time. All (in my case) Cubebase files were just -1, -2 suffixes and it worked. I had continuous backups, sure and it just kinda worked at the time.
Given I now use Git heavily in my work/hobby life, when doing other projects (3D models for printing (questionable at best) and artwork (very very very questionable at best)) I definitely wanted to use some sort of SCM.
I opted for these for Perforce - mostly to experiment, but also the idea of having binaries in a distributed SCM. Yes, I know Git-LFS _exists_, but also, to me it breaks the idea of what Git is.. relying on a server for binaries in a situations where everything should be distributed.
If I now went back to audio-production, I would probably consider either Perforce or SVN. Perforce only if it were for a single user (because of licensing). The ability to clone/checkout a single directory of a repo at a given point in time natively and make modifications and push them back is almost quite necessary when dealing with very large files.
And I still use SVN for _some_ situations - particularly those where Perforce is overkill and all I want to _always_ HEAD and the rest is history (for manual preservation history) and no such need for merging and branching (thinking Wiki and other plain-text tooling).
In the case of any sort of any binary-merging - I _heavily_ assume this isn't expected in the poster's situation!
I originally wrote the speach in my blog repo, just for writing purposes.
My dad's funeral was yesterday and wondered, maybe, someone might appreciate it - either because they've lost their dad or it makes them appreciate their dad a little more.
> effectively turning the developer's most trusted assistant into an unwitting accomplice
"Most trusted assistant" - that made me chuckle. The assistant that hallucinates packages, avoides null-pointer checks and forgets details that I've asked it.. yes, my most trusted assistant :D :D
Well, "trusted" in the strict CompSec sense: "a trusted system is one whose failure would break a security policy (if a policy exists that the system is trusted to enforce)".
I don't even trust myself, why would anyone trust a tool? This is important because not trusting myself means I will set up loads of static tools - including security scanners, which Microsoft and Github are also actively promoting people use - that should also scan AI generated code for vulnerabilities.
These tools should definitely flag up the non-explicit use of hidden characters, amongst other things.
I wonder which understands the effect of null-pointer checks in a compiled C program better: the state-of-the-art generative model or the median C programmer.
Given that the generative model was trained on the knowledge of the median C programmer (aka The Internet), probably the programmer as most of them do not tend to hallucinate or make up facts.
This kind of nonsense prose has "AI" written all over it. In either case, be it if your writing was AI generated/edited or if you put so little thought into it, it reads as such, doesn't show give its author any favor.
Sure, you're right in most cases. In the use-case I had, it's a private registry with "immutable" tags (at least enough to stop accidental overwrites - and it is a homelab, so if someone else did it, I'd have worse problems ;))
The point was more about using null_triggers (or `terraform_data` I see) and using the trigger replacement, with the docker resources as purely an illustration.
Good point - I hadn't actually looked massively hard into solving it with this provider - I had to do it again for another use-case recently and decided to blog about it (and also try my hand at a short post).. but used this example from a while ago because it seemed much more relatable than the latest encounter :D
I guess, assuming you're not building the image, whether you use the data source of image probably isn't too important (assuming the data source is able to lookup images that aren't present on the local machine :thinking:).
Edit: and now I've seen that in the docker image resource, they reference using the data source to be able to track remote image SHA changes, in order to trigger an image re-pull :doh:
I've run into this exact thing. Luckily rebuilding a container doesn't cause downtime for us and 99% of our changes require rebuilding an image, so I've just left it as is...
It is annoying though when we make a small infra change and have to wait for the container image to build...
Similarly, older versions (<3.0) of the provider had a `build` attribute for the `docker_registry_image` resource, which made it possible to build and publish an image to a registry, without causing unnecessary rebuilds if there was no local version of the image on the build host.
Now you have to use the `docker_image` resource to build a local image on the build host, and then use the `docker_registry_image` resource to publish it to the registry. In a CI/CD scenario with ephemeral runners, there will never be a local version of the image on the build host, so the image will always be rebuilt on every Terraform run, even if there are no changes to it.
It's a tricky problem to solve from a provider design standpoint, since building a Docker image necessarily creates a local Docker image on the build host, which may not be a desirable side effect for the `docker_registry_image` resource to have and raises other design questions with no universal answers (Should it delete the local image after building? What if there's already a local image with the same name/tag, but it's not in the Terraform state; should it use the existing one or build a new one and overwrite the existing one? If the `docker_registry_image` resource is removed, should any corresponding local images also be delete? etc.)
I saw the no DVD and was initially devastated. I'm in two minds - I saw one post that basically said "it won't contain a DVD at launch".. if I read between the lines, though I'm not sure I see the value incentive for Rockstar, but...
If they hypothetically launched with physical boxes with digital download codes, okay... This would definitely be in the name of re-sellers (as they've stated). But this is the same as piracy, which has always been, not that "we need to stop people from pirating our games for eternity" but "we need to stop people pirates our game for X months after launch", which makes sense (the piracy party).
So, I'm wondering, if they actually begin releasing physical disks (offline, re-sellable, usable in 20 years), say, 6-12 months after releasing the game.. would that work? I mean, for me, assuming it's the equal block-buster to the franchise I adore (in a varying sense), then I might not mind too much to pick up a copy after 6-12 months (I don't care about bleeding edge).. but... would this work? If we assume the first 12M of buyers can't resell, would the people who buy the game after 12M actually bring a great number to the second hand market.. perhaps not?
I really have the idea of having games that I love in physical form that I know it can't be taken away.. similar to reading a book that you end up reading and know you want to come back to anytime in the future.. and this would _suck_ if I couldn't get a copy (and I assume all PC versions would be full of online-only DRM stuff anyway).
Ergh, I dunno