• 0 Posts
  • 69 Comments
Joined 1 year ago
cake
Cake day: August 30th, 2025

help-circle

  • That’s tight fit. If you really need the two capture cards then that’s the room you’ve got to work with. If you can bring it down to just one card at the top that would be a lot better. I personally use a capture card that’s connected using USB3, which works very well and doesn’t require room inside the computer (even though I would have room).

    Most videocards have two or three fans on the bottom these days, with such a tight fit one of the fans can easily collide with the capture card. And even when it doesn’t it will have a hard time sucking in air from there. You can try and find a blower type card, but that would be a bit harder to find.

    And you wouldn’t happen to have a GPU inside the CPU? Because the iGPUs from AMD are very solid if you don’t need much in terms of performance (easily faster than the 1030 you mentioned). Otherwise two capture cards and a GPU is a big ask in such a small case.


  • The A series is pretty limited, I would go for a B series if you can find it. But keep in mind drivers for Intel on Windows are terrible and on Linux even worse. So that would not be a good time.

    There’s plenty of cards that would fit in 40mm, but your airflow would be pretty bad. Do you have a pic of the inside of your system? There has to be a way to make something more fit.

    But most 6600, 7600 and 9060 cards should be able to fit in 40mm. And with AMD the drivers on Linux are very good.







  • Reminds me of the first time I saw Sin and Cos lookup tables being used in early 3D gaming. The computers could calculate those just fine, especially with a math co-processor. But for 3D gaming it would be too slow to get a good framerate. So lookup tables were used to greatly improve the speed.

    Back on those days all sort of neat tricks like that would be used. Often done as little demo programs that were very impressive. Before the internet it was hard to look up something like that and the latest and greatest tricks weren’t written in books yet. So often little code snippets and demo programs would be shared amongst programmers using the sneakernet, so we could all learn and get better.





  • Thorry@feddit.orgtoScience Memes@mander.xyzSuperb cool
    link
    fedilink
    English
    arrow-up
    16
    ·
    4 months ago

    And keep in mind there weren’t just large beasts, but small ones as well. People tend to focus on the big ones, because they are most impressive, but they came in the full range of sizes. Just imagine how alien our planet looked compared to what we are used to now.


  • Because methane is a byproduct of the petroleum industry, it’s very cheap. They have so much gas, they torch of a whole lot of it all the time. Which is a good thing, because releasing it as CO2 is actually better than releasing it as methane, obviously releasing it at all is a really bad thing.

    It being so cheap makes it really hard for alternative sources to be viable, since it would be more complex and thus more expensive. It is done, but mostly because of regulation, subsidies and as an environmental measure.

    Methane does break down fairly fast (still takes years), we keep releasing so much of it, it does contribute a lot to climate change. We are adding more than gets broken down. And even after it breaks down, it’s still contributing to the amount of CO2, so better but not good.





  • Very good! Your spidey senses are working perfectly. Hey I want to comment this calculation, why don’t I move it into a function so the name can explain what it does. Good call!

    Sometimes the algorithm is inlined for performance, sometimes it’s a class with a bunch of functions that as a whole is primarily based on an algorithm, so comments might make sense in those cases. Most of the times it’s a library, so the name of the library kinda gives it away and hopefully has good documentation as well.


  • Thorry@feddit.orgtoProgrammer Humor@programming.devfuck you bill
    link
    fedilink
    arrow-up
    41
    arrow-down
    2
    ·
    5 months ago

    Asking an LLM to add comments is actually pretty much the worst thing you can do. Comments aren’t meant to be documentation and LLMs have a habit of writing documentation in the comments. Documentation is supposed to be in the documentation, not in the code. LLMs are often trained on things like tutorials, where super obvious statements are commented to allow people to learn and follow along. In actual code you absolutely do not do this, obvious statements should be obvious by themselves. At best it’s extra work to read and maintain the comments for obvious statements, at worst they are incorrect and misleading. I’ve worked on systems where the comments and the code weren’t in line with each other and it was a continual guess if the comment is the way it was supposed to work, or if the code is correct and the comment wrong.

    So when do you actually add comments? That’s actually very hard, something people argue about all the time and a bit of an art form to get right. For example if I have some sort of complex calculation, but it’s based on a well known algorithm, I might comment the name of that algorithm. That way I can recognize it myself right away and someone that doesn’t know it can look it up right away. Another good indicator for comments are magic numbers. It’s often smart to put these in constants, so you can at least name them, but a small little comment to indicate why it’s there and the source can be nice. Or when there is a calculation and there’s a +1 for example in there somewhere, one might ask why the +1, then a little comment is nice to explain why.

    Comments should also serve like a spidey sense for developers. Whenever you are writing comments or have the urge to add some comments somewhere, it might be an indicator the code is messy and needs to be refactored. Comments should be short and to the point, whenever you start writing sentences, either start writing documentation or look at the code why it’s required to explain so much and how to fix that.

    Another good use for comments is to warn away instincts for future devs. For example in a system I worked on there is a large amount of code that seems like it’s duplicate. So a new dev might look at it and see a good place to start refactoring and remove the duplicated code. However the duplication was intentional for performance reasons, so a little comment saying the dupe is intentional is a good idea.

    I’ve also seen comments used to describe function signatures, although most modern languages have official ways of doing that these days. These also might border on documentation, so I’d be careful with that.

    LLMs also have a habit of writing down responses to prompts in the comments. For example the LLM might have written some code, you say: Hey that’s wrong, we shouldn’t set x to y, we should set it to z. And the LLM writes a comment like // X now set to Z as requested. These kinds of comments make no sense to people reading the code in the future.

    Keep in mind comments are there to make it easier for the next guy to work on the code, and often that next guy is you. So getting it right is important and hard, but very much worth while. What I like to do is write code one day and then go back and read it the next day or a few days later. And not the commit, with the diff and the description, the actual files beginning to end. When I think something is weird or stands out, I’ll go back and edit the code and perhaps add comments.

    IMHO LLMs are terrible at writing code, it’s often full of mistakes and oversights, but one of the worst parts is the comments. I can tell code was AI generated right away by the comments and those comments being present are a good indicator the “dev” didn’t bother to actually read and correct the code.