Command and Conquer was almost certainly my first exposure to him. I guess it's time to go replay Red Alert 3 and enjoy those cutscenes all over again.
A regular yearly replay is in order for me, too. Already done with SC2... just SC1/WC3/DoW(2)/RA2(mental/flippedmissions/etc)/RA3(uprising)/HOMM3/etc/etc/etc. Ah well.
An underrated fallacy in general. (Of course I'm just giving a common name to something that was identified, not accusing anyone of having the etymological fallacy in this conversation.)
Yeah, I built mine in 3090 times and told myself I'd upgrade every 2-3 GPU generations. I do have 128G ram and I'm thankful for that but I'm definitely not on the same upgrade schedule any more.
I have 32GB and an aging 5800X3D and I have not had any issues running games yet. Honestly would love to know what games need more powerful RAM/CPU outside of stuff like Flight Simulator, or running at 160fps without framegen.
Honestly I have a steam deck and that has gotten me accustomed to not sweating the lower frame rates. That and the ridiculous number of great indie games that aren't heavy on the graphics, and I'm not too worried about upgrades as much as I am worried about replacements if/when the time comes.
I like to think of myself as pretty well-versed when it comes to hardware and software and even some RF. But this conversation has me hitting search a lot, lol. It's fascinating reading experts talk about a domain I have less experience in.
Heh, welcome to RF; there are more rabbit holes to go down in domain specialty than I think there are grains of sand on a beach. I've gone down like... two. And I'm pretty overwhelmed.
I think that's why a lot of EEs and developers wind up getting an amateur radio license, or at least running a few fun RF projects.
Glad I’m not the only one. I’ve been tinkering with sensors, robotics, sdr and similar stuff for 20 years now, but this conversation was way over my head.
Showing its age is also a pretty significant plus, for such a critical part of one's infrastructure. That means it's been beat up on and run through the ringer for a decade plus at this point and had lots of chances to fix CVEs and other bugs. Not to say there won't be more, but being older and time-proven for an IdP is a major positive.
I hope/wonder if it will go the way computers did. We may learn to more effectively build RAM or parallel compute, and use it more effectively, in the coming decade in such a way that we can democratize more and more like we did with processors to the point that they're ubiquitous.
I would call it clever. I'm not sure I'd call it genius.
When I'm working with data I'm working in a specific set of languages. Usually one. Yeah, other people might be working in other languages, but no individual author really needs a language-agnostic way of accessing data beyond compile time. Add to that the likely runtime boundaries that may need to be crossed instead of e.g. inlined by the compiler because it's in-language and dealing with known offsets or tags (depends on the data format of course). To the other commenter's point, am I going to have to sandbox all data access code just to be sure it's not able to do something unexpected? There's a lot of complexity here. And the inherent risk is going to slow down the operation that should be the simplest and fastest: interpreting bytes.
A big problem with parquet, which this aims to replace, is that it's hard to add new encodings because everyone wants to stay compatible with old readers. Embedding the decoders in the file as WASM solves this problem since in theory, old readers will be able to read new files by just using the provided WASM to decode a column whose format the reader doesn't recognize.
So this is really about making a file that is forwards compatible in a way that lets you push the standards more than existing formats.
>no individual author really needs a language-agnostic way of accessing data beyond compile time.
That's so untrue! People need language-agnostic ways to access data all the time, and people work with data accessing them from multiple languages all the time!
If I have parquet files I can load them in duckdb, in pandas and polars, process them with various independent tools, and loads of other things... and people do that.
This is also why people like something like an SQL database, your data is not locked to some specific language / lib for access.
Text: You have rights to what you make.
Music: You own what you make.
reply