𝒍𝒆𝒎𝒂𝒏𝒏

Hey 👋 I’m Lemann: mark II

I like tech, bicycles, and nature.

Otherwise known as; @lemann@lemmy.one and @lemann@lemmy.world

Dancing Parrot wearing sunglasses

  • 0 Posts
  • 36 Comments
Joined 11 months ago
cake
Cake day: December 22nd, 2023

help-circle


  • ASMedia is the only controller IC manufacturer that can be trusted for these IME. They also have the best Linux support compared to the other options and support pass-through commands. These are commonly found in USB DAS enclosures, and a very small fraction of single disk SATA enclosures

    Innostor controllers max out at SATA 2 and lock up when you issue pass-through commands (e.g. to read SMART data). These also return an incorrect serial number. These are commonly found in ultra cheap desktop hard drive docks, and 40pin IDE/44pin IDE/SATA to USB converters

    JMicron controllers (not affiliated with the reputable Micron) should be avoided unless you know what you are doing… UASP is flaky, and there are hacky kernel boot time parameters required to get these working on Raspberry Pi boards. Unfortunately these are the most popular ones on the market due to very low cost



  • I wholeheartedly agree with this tbh. Love FreeCAD for my 3D printing stuff, pretty much use it daily, however compared to something like Solidworks or AutoCAD it would be torture IMO to willingly chose FreeCAD for a complex real world product.

    The biggest roadblock for FreeCAD right now is that is isn’t that forgiving, you often have to go into a “technical” way of thinking to work around its quirks. The reality is, designers want to design, not become technical experts at navigating FreeCAD.

    Even something like creating a thread shouldn’t be as involved as FreeCAD makes it - once you get used to it it’s OK, but in other CAD solutions it’s often as simple as clicking a hole and choosing a thread creation tool…




  • I used to use MQTT, static_status and Healthchecks.io, and have that data passed through to Home Assistant, but it started to get pretty cumbersome as the amount of machines I had grew.

    I now use just Zabbix and HealthchecksIO. I did need to spend some time writing new templates for some additional data I wanted to collect (like SMART data for SSDs that provide health metrics in non-standard attributes, and HealthchecksIO so I could see the status of various checks on my zabbix dashboard)

    Zabbix also has some additional features I found appealing, like proxies that can continue recording data when the main server is down, and built in encryption. Some checks like open ports/icmp responses etc can be checked using either the local agent, the remote server, or both, which helps quickly diagnose things like firewall config issues.

    I did look at some other solutions, but I wanted something integrated to hit the ground running. Mobile apps are very limited, and there is no official one to my knowledge. I use Moobix which I don’t believe is FOSS - but I could be wrong there

    Try each solution out and see what works best for you!








  • If anyone is interested in mitigation, the only way around this AFAIK is to start with a brand new domain, only use wildcard certs (with DNS validation), and don’t bundle multiple renewals into a single cert.

    Also, don’t enter your domain or related IP address into dns reverse engineering tools (like dnsdumpster), and check certificate transparency logs (https://crt.sh) to see what information related to your cert renewals has been published.

    This won’t stop automated bots from scanning your ip for domains, but should significantly reduce the amount of bots that discover them



  • Not exactly IMO, as containers themselves can simultaneously access devices and filesystems from the host system natively (such as VAAPI devices used for hardware encoding & decoding) or even the docker socket to control the host system’s Docker daemon.

    They also can launch directly into a program you specify, bypassing any kind of init system requirement.

    OC’s suggestion of a chroot jail is the closest explanation I can think of too, if things were to be simplified




  • A lot of the libcamera work done on Raspberry Pi boards is going towards improving the camera support on linux phones like the PinePhone, which is great!

    Aside from that, sadly a lot of people (including myself) are kind of fed up with Raspberry Pi, after they essentially abandoned their mission during Covid to please corporations, and are preparing to go public despite being a “charity”. Broadcom, their SoC supplier, also has left a sour taste in my mouth after their purchase and mass layoffs at VMWare.

    If they created a phone it would likely end up being scalped to death, and maybe pretty pricey compared to a PinePhone