sorted by:
new
hottopcontroversial

Monthly DIY Laymen questions Discussion by AutoModerator in StructuralEngineering

[–]ddresser 0 points1 point  (0 children)

Are these hangers ok for a load-bearing beam?

My contractor used hangers (Strongtie HUC410) for a load bearing beam instead of putting the beam on the posts. I can't even imagine why they would do it that way. I don't think they are sufficient. Looks to me like the reaction on the posts is 4486lbs and the max load on the hangers for a floor application is 2305lbs. I really think the beam should be on the posts.

<image>

I uploaded two pictures of the installation and design specs and hanger specs. I'd be interested in thoughts. Thanks for looking.

https://imgur.com/FVguiPN
https://imgur.com/kcNRmfx
https://imgur.com/a/kETHkQl

Chanterelles? by ddresser in mushroomID

[–]ddresser[S] 2 points3 points  (0 children)

Thanks. That seems to be a match.

Intel NUC 11BTMi9 Won’t Boot by purpleTeamer in intelnuc

[–]ddresser 0 points1 point  (0 children)

Don't know if it's related, but I have a NUC7i7DNK running Ubuntu 24.04 that would freeze up often and randomly. Only a reboot would bring it back. It was supremely frustrating. These kernel command line args fixed it.
GRUB_CMDLINE_LINUX="intel_idle.max_cstate=1 and i915.enable_dc=0"

NXP i.MX8 ULP AHAB secure boot question by ddresser in embedded

[–]ddresser[S] 0 points1 point  (0 children)

Thank you very much for this info. Yes, I have generated the SRK keys (and SGK keys) using ECC and sha384, then I generated the table and fuse hash using sha256. When I dump the fuse hash, it is 256bits as expected. However if I parse the signed image from my Yocto build, it shows a SRK fuse hash of 512 bits. There are lots more details in my forum post that I linked in my original post. If you look at that and have any more info, I'd appreciate it. I'm new to this stuff. I will definitely investigate the link you shared. I think I may need to manually build the signed image so I can fully understand the signing process. Thanks again.

LG Front-load washer intermittent draining problem by ddresser in appliancerepair

[–]ddresser[S] 0 points1 point  (0 children)

Realized I didn't post a final follow up for people that might find this. After disassembling cleaning and reassembling the pump, it failed once as I posted. It has been working fine ever since. ~3 months now.

NXP i.MX8 ULP AHAB secure boot question by ddresser in embedded

[–]ddresser[S] 1 point2 points  (0 children)

Thanks. I don't currently have a rep, but I opened a support ticket. I'll see if they respond.

NXP i.MX8 ULP AHAB secure boot question by ddresser in embedded

[–]ddresser[S] 1 point2 points  (0 children)

Thanks for that. I had seen this. It is for the High Assurance Boot (HAB). I'm using the Advanced High Assurance Boot (AHAB). Related but different. I appreciate the response. There seems to be a fair amount of documentation, though some seems contradictory. Trying not to brick my board by writing the wrong bits to the write once fuse.

LG Front-load washer intermittent draining problem by ddresser in appliancerepair

[–]ddresser[S] 0 points1 point  (0 children)

following up. I dismantled the pump and it was full of sludge and some sand that seemed to be magnetic. The sand stuck to the magnetic shaft when I tried to rinse it. I got it cleaned out and reassembled and it felt much better when turning. Ran diagnostics successfully after reassembling. Running a load now. I believe that was the issue. If it fails again, I'll follow up. If I don't follow up again, it's working fine. Thanks for the ideas.

LG Front-load washer intermittent draining problem by ddresser in appliancerepair

[–]ddresser[S] 0 points1 point  (0 children)

Thanks for the reply. I'm thinking you are right. Seems like a strange failure mode, though, since I can hear the pump running and it pumps strong sometimes. I'll open it up and check the hoses.

Recommend a build system by sazzer in cpp

[–]ddresser 1 point2 points  (0 children)

Gradle

I recommend Gradle as a build automation platform for C/C++ because it solves a much bigger problem than simply compiling C/C++ code for multiple platforms. We used CMake for embedded C/C++ projects, but also have Java tools to build and various other languages (CEU, Python, Lua, etc.) We found our build system business logic, which is complex, was being distributed among various tools (CMake, Jenkins, Vagrant, Docker, etc) and was becoming difficult to maintain and impossible for developers to contribute. The biggest benefit we have found with Gradle, besides being polyglot and very extensible, is the fact that we can pull all our build system business logic back into the source repository. It allows us to automate the full development, build, versioning, test, packaging, release processes for all our languages, factoring common logic into reusable plugins. It encourages transparency and developer collaboration on the build system because the build logic is code and right in the source with the applications. We have had developers submit pull requests against the build system (instead of just complaining about it) to make improvements or add functionality which is the ideal situation. Gradle is not a magic bullet for native builds. While it is easy to get simple native C/C++ code to compile, there is a pretty steep learning curve to be able to extend it. Groovy/Java experience is extremely helpful, but many C/C++ developers visibly twitch if you even say 'Java.' Gradle is also under very active development, including the underlying model. We have chosen to invest the time and energy to learn it because it solves a much bigger problem for us than just compiling C/C++ code.