Surely tape saturation or the artifacts/tone coloring of vinyl records would have been a better example.
3,634 karma · joined May 9, 2019
My perspective is biased by the fact that such communities are an important part of my life. I don't want to see my years-long collaborations and friendships made obsolete by someone looking for an afternoon of nostalgia. And maybe everything will be fine, and the AI-users and the community-builders will go their separate ways and leave each other alone. But communities which exist today are having to ask how we should relate to AI, and my conclusion is that it's best kept out of hobbyist spaces if we want those spaces to continue to exist.
To what end? The biggest benefit of tinkering with 40-year-old hardware is the experience of doing so. The knowledge and intuition you learn about how computers really work; the friendships you develop through collaboration with others, through asking for help with your projects and helping others with theirs; and the relaxing Saturday afternoons spent investigating and debugging and experimenting. The "benefit" of having a game that's been recompiled to a native executable for your PC or whatever is marginal compared to the benefit of the process to get to that point. That end goal is just a lighthouse to keep you on track, and when you get there maybe you'll play the recompiled game once to celebrate a job well done before moving on to another project.
If writing software is a means to an end, then there's value in anything that reduces the effort to get to that end. But as I see it, retro gaming projects are mostly an end to a means.
> Seems pretty egoistical when nobody's forcing you to use AI in any way, it provides an objective benefit to other people.
I have three fundamental claims:
- There is little to no positive benefit to using AI for hobby projects whose completion provides little to no intrinsic value.
- Choosing to do so has a negative impact on you, as it bypasses an incredibly valuable learning experience.
- Choosing to do so has a negative impact on others, as it takes away someone else's project opportunity (there are a finite amount of popular retro games, and many people prefer to work on novel projects rather than recreating something that has already been done).
I'm not sure what's "egoistical" about that, and I'd love if you could elaborate on that because I'm still wrestling with the ethics and implications of all this myself. The way I see it, it's better if I choose to forgo the use of AI on my projects, and I think others should choose the same.
---
Many years back, one retro gaming community I'm a part of had a prolific contributor who was extremely knowledgeable about the game, but also incredibly abrasive. He was the most knowledgeable person in the community at the time, and held this over others; discrediting their achievements, discouraging their attempts to learn, constantly starting fights and driving many good people out of the community. Yet he was allowed to remain in the community for many years, because everyone thought we needed his expertise.
Eventually the community came to the realization that it's just a video game and we don't "need" anything at all. None of the long-term community members are really here for the game anymore; we're here for the experience and the camaraderie. So we should make decisions (like kicking out this member) that are technically suboptimal for the game (at least in the short term), but better for fostering the community.
In a similar vein, using AI within these sorts of hobby spaces may allow faster progress on such projects, but it takes away the value of completing the projects in the first place, to the detriment of both the individual and the community.
So having Claude one-shot a NES emulator is almost pointless to me. You're using and looking at source code for an emulator you didn't write -- and you can learn from that, but it's not the same thing and doesn't require you to really understand a CPU the way you would by, say, observing a deviation in game behavior and staring at trace logs to figure out the exact instruction you emulated incorrectly.
It's not all bad -- AI is a great research tool and can automate some of the tedious parts (writing out an instruction decoder by hand is miserable). But using it to just...skip over the effort of doing a project defeats the whole purpose of doing those projects in the first place.
I don't want to be gatekeepy or curmudgeonly or "back in my day..." about it. But for me, my entire career path is due to skills and knowledge I learned spending several years of my life as a teenager figuring out how to write an NES emulator as a relative beginner to programming. And so I feel like using AI for this is depriving the next generation of that learning process. In addition, there are only so many retro games, and fewer popular ones. There's only so much unexplored territory to discover, and doing it with AI deprives another person of that experience and deprives that game's community of someone who might have been able to find a "home" working on projects related to that game.
Pangram claims a 1 in 10,000 false positive rate (rate at which human-authored texts are incorrectly classified as AI-generated). 1 in 200 sounds like the false negative rate (rate at which AI-generated texts are classified as human-authored), or perhaps a rate for a specific category of text.
The only Wikia sites that had anything worthwhile were the ones that started as independent communities and got bought out, like Memory Alpha or the Minecraft wiki.
> Sign in with Apple addresses, previously issued on privaterelay.appleid.com, will be issued on private.icloud.com.
> iCloud+ Hide My Email addresses will remain on icloud.com.
> If something goes wrong in this process—the overwhelmingly most likely one is that the payer doesn’t have the funds to cover the check (NSF, or “insufficient funds”), but the check being fraudulent or unauthorized is also possible—that wrongness may not be discovered before money “moves” to your bank. And so that payment can be recalled from your bank to the bank the check is drawn on. This will likely result in the bank attempting to recall the money from your account.
> And so by presenting your check, which you think is substantially terminating a transaction, you are actually creating a new credit extension with your bank. They are extremely aware that you just asked them to advance you money, even if you are not aware that you did that. They already partially underwrote this extension of credit; that is why you were not shooed out of the building when you originally asked for a checking account.
Then I saw an actual performance of the play recently, and it all clicked. It was just as understandable as any contemporary film, and easily one of the most fun and entertaining stories I've seen.
Bellard hasn't worked on FFMpeg since 2003.
This comment spawned two subthreads. One of them was focused on the differences between Rust and Zig's compilation model, which is directly relevant to the article and illuminating regarding the engineering tradeoffs.
In the other subthread, pron posted paragraphs and paragraphs arguing about what memory safety really means and whether or not Steve is right to have his opinion that Rust is "safe". This tangent had essentially nothing to do with the content of Steve's comment; it (and not Steve's initial comment) was the point where the thread was derailed from the topic of Zig's incremental compilation model. Steve responded politely in this thread to comments and questions directed at him, but did not fan the flames or take the thread further into off-topicness. If the moderators collapsed pron's comment or detached it and pinned it to the bottom of the page, this comment thread would be much better and much more respectful to the Zig project.
I think the RESF trope is just about dead now; it's given way to the Rust Detractor Strike Force showing up to turn unrelated threads into tangential arguments about why Rust is bad.
The downside is that functions which are called from multiple dependent crates will need to be codegen'd in each of their dependents, so this can increase compile times if the crate is not "mostly unused."
So it's not quite as powerful as full demand-driven compilation, because of how Rust separates the compilation process into separate crates.
Things are slowly getting better here! '&raw'/'&raw mut' reference operators were stabilized a couple years ago.
Another ergonomic improvement in the pipeline is a better way to access fields behind pointers, something like C's -> operator. This is taking some time to design because there are things other than raw pointers that would benefit from a generalized field projection mechanism, like Pin, NonNull, and (potentially user-defined) smart pointer types.
There are roughly two categories of Rust user:
1. People who are using Rust for application development. Most of these users write zero unsafe blocks in their careers. For these users, "memory safety" was probably not a strong reason to pick Rust, because there are a wealth of other memory-safe application development languages out there.
2. People who are using Rust for systems programming (i.e. programming under resource or environment constraints). These users may write unsafe for performance reasons, or to do things like hardware MMIO; and they're using Rust over C/C++ either for security or just because the tooling is nicer.
The first category of user is unlikely to consider C for application development in this decade; they're going to be comparing Rust against Go or Java or Node.js. Fil-C solves the security problem of memory safety, but it does not free the developer from the difficulty of having to manually write memory-safe C code; their program will just crash if they get it wrong.
The second category of user cannot use Fil-C because of its performance overhead, runtime requirements and/or lack of escape hatches for MMIO/FFI.
Where Fil-C does shine is for legacy application software written in C. Here, it's a free lunch: a way to harden the massive amount of existing software without an expensive rewrite. I would love to see distros shipping pizlonated coreutils, ffmpeg, systemd, curl, sudo, postgres, etc., anything that has a big attack surface, but does not need to be memory-unsafe.
This is a problem I care about a lot, and your work here is truly a monumental advancement in the field. Comparisons to Rust sell it short by inviting endless debate on problems largely tangential to Fil-C.
With Fil-C, the "unsafe blocks" live entirely within the compiler and runtime. With Rust, the unsafe foundation is the Rust compiler and standard library, as well as any unsafe code within your application or dependencies.
So either way you're in the same situation of relying on the correctness of the unsafe code you depend on. But there are two major differences:
- Unsafe code can be written in Rust, instead of inside the compiler. This is much easier to write and to review for correctness.
- People other than Fil are allowed to write unsafe Rust. This is what Fil's point is about, and yes, it allows you to opt-in to increasing your attack surface by trusting unsafe code written by yourself or your dependents. Rust allows the user to choose where they draw the trust boundary, and Fil-C does not.
It's true that Fil is probably better than I am at writing unsafe code. So "Fil-C is safer than Rust" is true in that sense. But Fil-C is certainly not safer than safe Rust. And sure, you can't run all the Rust code in the world if you compile with '--deny unsafe_code'; but Fil-C can't run all the C code in the world either. Unsafe Rust is rarely needed, mostly only if you want to do pointer crimes or FFI, and Fil-C doesn't support a lot of (perfectly legal) pointer crimes and FFI either.
This is not the case, level data is stored in full. One reason for this is that level generation is pretty slow (compare the time it takes to create a new world vs. load an existing one); another reason is that it changes between versions.
The videos are heavily edited with many cuts. So, I'd guess the production process is "have him talk for an hour, then edit it down to a 10 minute YouTube video".
> In any event, Rick Beato seems like a normal human being, albeit a somewhat goofy dad-rock oldie. 12Tone comes across as an aspie weirdo. I'd rather have more of the former.
And that's...kind of the point I'm making? The amount of effort put into the content of Beato's videos is quite low, with probably a couple hours at most of time put into research, coming up with talking points, and recording. But a lot of effort is spent on production, in order to make content that feels relatable and punchy and palatable to a mass market. It's junk food, and junk food sells well.
As a musician myself, and as someone who enjoys watching music and music theory content on YouTube, I can't stand watching Rick Beato because of stuff like this. There certainly are valid criticisms to be made against the music industry, but those videos are like 90% ridiculous cherry-picked comparisons and vague, superficial justifications. It's low-quality nostalgia-driven engagement bait that's optimizing for clicks and comments.
I really like this video by 12tone addressing Beato's schtick about modern music [0]. 12tone is an example of someone who I consider produces much higher quality content than Beato, and obviously puts a ton of time and effort into the videos (writing scripts, drawing the visuals, recording and editing, and making moderately-clickbaity titles and thumbnails). But I'd guess it's probably a one-person operation.
In comparison, Beato's channel strikes me as low-effort content (pick a topic and spend an hour talking unscripted in front of a camera) with a ton of money spent on production, editing, and algorithm hyper-optimization to maximize ROI. It's such a straightforward case of something that would not exist without YouTube's monetization system that it's rather ironic for the parent to use it as an example otherwise.
I don't know if there were any actual machines that used dual PPUs, but the functionality was likely intended for creating an arcade machine with dual-layer background graphics.
Obviously, the situation has changed in recent years, so it's now considered a much higher priority by many people and some of them are actively working on it. But it's a lot of work to be done by volunteers, so it takes time.
That's the reality of open-source projects: things get done when they are important enough to motivate someone to either fund it or work on in their free time, not according to idyllic roadmaps and schedules.
How is a different (and longer) keyword "far more readable"? That's just a matter of preference and familiarity. The reason for choosing a different keyword is that it's not quite equivalent to an unless as the {} block must exit the surrounding scope. You read it like an assert statement with a custom handler.
> Moreover, there are many languages where an assignment or an initialization can appear in any place where an expression can appear. Such general rules are always better than special rules like allowing new bindings in a "guard", but not in an "if".
You can introduce bindings in an if too. The special thing about guard is that you can introduce a binding which is valid for the remainder of the scope outside the {} block (where the condition is true) but not inside (where the condition is false).