"Industry hearsay" in this case was probably Sony telling game devs how awesome the PS5's custom SSD was gonna be, and nobody bothered to check their claims.
the "industry hearsay" from two replies above mine is about deliberate data duplication to account for the spinning platters in HDD (which isn't entirely correct, as the team on Helldivers 2 have realized)
HD2 started as playstation exclusive, and was retargeted mid-development for simultaneous release.
So the PS5's SSD architecture was what developers were familiar with when they tried to figure out what changes would be needed to make the game work on PC.
If what they were familiar with was a good SSD, then they didn't need to do anything. I don't see how anything Sony said about their SSD would have affected things.
Maybe you're saying the hearsay was Sony exaggerating how bad hard drives are? But they didn't really do that, and the devs would already have experience with hard drives.
What Sony said about their SSD was that it enabled game developers to not duplicate assets like they did for rotating storage. One specific example I recall in Sony's presentation was the assets for a mailbox used in a Spider Man game, with hundreds of copies of that mailbox duplicated on disk because the game divided Manhattan into chunks and tried to have all the assets for each chunk stored more or less contiguously.
If the Helldivers devs were influenced by what Sony said, they must have misinterpreted it and taken away an extremely exaggerated impression of how much on-disk duplication was being used for pre-SSD game development. But Sony did actually say quite a bit of directly relevant stuff on this particular matter when introducing the PS5.
Weird, since that's a benefit of any kind of SSD at all. The stuff their fancy implementation made possible was per-frame loading, not just convenient asset streaming.
But uh if the devs didn't realize that, I blame them. It's their job to know basics like that.
By far the most important thing about the PS5 SSD was the fact that it wasn't optional, and developers would no longer have to care about being able to run off mechanical drives. That has repercussions throughout the broader gaming industry because the game consoles are the lowest common denominator for game developers to target, and getting both Xbox and PlayStation to use SSDs was critical. From the perspective of PlayStation customers and developers, the introduction of the PS5 was the right time to talk about the benefits of SSDs generally.
Everything else about the PS5 SSD and storage subsystem was mere icing on the cake and/or snake oil.
Yeah, that's what I was trying to get at. Sony was extremely deceptive in how they marketed the PS5 to devs, and the Helldivers dev don't want to admit how completely they fell for it.
It's incompetence if they "fell for" such basic examples being presented in the wrong context. 5% of the blame can go to Sony, I guess, if that's what happened.
And on top of any potential confusion between normal SSD and fancy SSD, a mailbox is a super tiny asset and the issue in the spiderman game is very rapidly cycling city blocks in and out of memory. That's so different from helldivers level loading.
I don't really understand your point. You're making a very definitive statement about how the PS5's SSD architecture is responsible for this issue - when the isssue is on a totally different platform, where they have _already_ attempted (poorly, granted) to handle the different architectures.
See also, FreeBSD: Plenty of commercial offerings around it, no source for most of them, because the license doesn't require it. For example, there's no source for the Playstation kernels/userlands released by Sony. They only upstream some bug fixes that would be too onerous to keep in their private fork.
> Some implementations have permitted anonymous member-structures and -unions in extended C to contain tags, which allows tricks such as the following.
struct point { float x, y, z; };
struct location {
char *name;
struct point; // inheritance in extended C, but
// forward declaration in C++
};
> This proposal does not support that practice, for two reasons. First, it introduces a gratuitous difference between C and C++, since C++ implementations must treat the declaration of point within location as a forward reference to the type location::point rather than a definition of an unnamed member. Second, this feature does not seem to be used widely in applications, perhaps because it compiles differently in extended C vs. C++.
If C and C++ standardization had included both languages since the beginning, compatibility could have been a thing but it didn't so the languages have diverged since C-with-classes.
I don't understand why the C standard has to get bogged down with bizarro-world-C restrictions from C++.
You do realize there are a lot of projects written in C, right? Including Linux and most of its programs / utilities that you may be using.
I have new projects written in C, too, and you can do a lot to check for potential bugs using various flags to GCC / Clang, among other things like cppcheck and the rest.
No, people should not give up on C. C is really good to know, for many reasons... even if you are not going to use it.
I believe GP meant that the idea of C/C++ should be abandoned, that is, that C and C++ are compatible languages. GP thinks that they should diverge more when necessary, none of them should be held back for the compatibility with the other.
The ISS served all political purposes it could, and microgavity research can be served by private entities these days. (Especially considering that a Starship has half the internal pressurized volume of the entire ISS, at approximately one thousandth the cost.)
A permanent Moon base would allow research opportunities that private LEO stations can't: ISRU, low gravity research, the far side of the Moon offers unique opportunities for astronomy (any spectrum), etc. pp. Long term, who knows what additional opportunities it opens up.
File roller does use 7z internally, so no real surprise here.
But both implementations can be vulnerable to malicious exe files, so it's not a great idea to do this with a file you already suspect to be malicious.
reply