• 0 Posts
  • 60 Comments
Joined 11 months ago
cake
Cake day: August 15th, 2023

help-circle

  • It was on old 3.5" drives a long time ago, before anything fancy was ever built into the drives. It was in a seriously rough working environment anyway, so we saw a lot of failed drives. If strange experiments didn’t work to get the things working, mainly for lulz, the next option was to see if a sledge hammer would fix the problem. Funny thing… that never worked either.




  • Maybe? Bad cables are a thing, so it’s something to be aware of. USB latency, in rare cases, can cause problems but not so much in this application.

    I haven’t looked into the exact ways that bad sectors are detected, but it probably hasn’t changed too much over the years. Needless to say, info here is just approximate.

    However, marking a sector as bad generally happens at the firmware/controller level. I am guessing that a write is quickly followed by a verification, and if the controller sees an error, it will just remap that particular sector. If HDDs use any kind of parity checks per sector, a write test may not be needed.

    Tools like CHKDSK likely step through each sector manually and perform read tests, or just tells the controller to perform whatever test it does on each sector.

    OS level interference or bad cables are unlikely to cause the controller to mark a sector as bad, is my point. Now, if bad data gets written to disk because of a bad cable, the controller shouldn’t care. It just sees data and writes data. (That would be rare as well, but possible.)

    What you will see is latency. USB can be magnitudes slower than SATA. Buffers and wait states are causing this because of the speed differences. This latency isn’t going to cause physical problems though.

    My overall point is that there are several independent software and firmware layers that need to be completely broken for a SATA drive to erroneously mark a sector as bad due to a slow conversion cable. Sure, it could happen and that is why we have software that can attempt to repair bad sectors.


  • Tin the wire and the pin first and then touch the iron to them both quickly. They should stick fairly well without needing to add additional solder. Also, like someone else mentioned, flux can help quite a bit. (Maybe even a cupped soldering iron tip might be useful, depending on the situation.)

    Learning how to solder SMD components will get you extremely familiar with how solder behaves at that scale. Let’s just say it’s significantly different than just doing basic wires and THT.

    (Well, the solder doesn’t really act different, but at smaller scales it looks like it does.)







  • I do. Also, I am old(ish) so I have had many years to come to terms with what I can do well and where I struggle.

    In this case, I didn’t want to use it as a crutch or an excuse. After reading the number of awesome replies this morning, I realized I should have probably framed my comment differently.

    People here put some real time and effort into giving some solid advice and I didn’t expect that.

    Edit: As a pure example, this is the third or fourth edit of this comment. Words are challenging, and programming is very similar in that regard.



  • remotelove@lemmy.catoProgrammer Humor@programming.devReview Please
    link
    fedilink
    arrow-up
    30
    arrow-down
    1
    ·
    3 months ago

    Some people, like me, are not built to be developers. I can sculpt code in any language I need for whatever problem I need to solve, but maintaining code over a long period of time, with others, is not my thing.

    The drive to do additional changes is just too high and the tendency for typos or obvious logic errors is too common. (There is one little improvement. It’s right there. One line up. Just change it now while you are in there…)

    I am not stupid and regard myself as a decent engineer but my brain is just wired in a more chaotic way. For some things that is ok. For developing code on a team, not so much.

    Security is the field I am most comfortable with because it allows for creative chaos. Rule breaking is encouraged. “Scripting” is much more applicable and temporary.


  • Sorry, my points were mixed unintentionally.

    I agree, I stay away from JVMs because they are a pain in the ass to administer and like you said, are usually coded by the lowest bidder.

    In a well maintained environment, I have nothing against JVMs actually.

    I was just bitching about the spring framework family. While security updates are frequent, Java apps tend to not age well and commonly suffer from version lock-in. (I am going through a round of that at my current job with spring auth stuffs being the offender.)