• 1 Post
  • 43 Comments
Joined 1 year ago
cake
Cake day: July 10th, 2023

help-circle

  • This would work but assumes the primary use of the machine is Windows and derates your performance under Linux significantly due to USB speeds. Even if you’re storing your data on the Windows HDD, NTFS drivers are dog slow compared to EXT4 and other *nix filesystems.

    Also some BIOSes are a pain to get to boot off removable drives reliably so it really depends on what your machine is.

    I’ve used Linux as a primary dev system for well over a decade now, and with the current state of Windows I’d really recommend just taking the leap, keep your Windows box if you need Windows software and build a dedicated Linux workstation.



  • That’s a valid point, the dev cycle is compressed now and customer expectations are low.

    So instead of putting in the long term effort to deliver and support a quality product, something that should have been considered a beta is just shipped and called “good enough”.

    A good example I guess would be a long term embedded OSS project like Tasmota, compared to the barely functional firmware that comes stock on the devices that people buy to reflash to Tasmota.

    Still there are few things that frustrate me like some Bluetooth device that really shouldn’t have been a Bluetooth device, and has non-deterministic behaviour due to lack of initialization or some other trivial fault. Why did the tractor work lights turn on as purple today? Nobody knows!


  • My type is a dying breed too, the guys who do their best to write robust code and actually trying to consider edge cases, race conditions, properly sized variables and efficient use of cycles, all the things that embedded guys have done as “embedded” evolved from 6800 to Pic, Atmel and then ESP platforms.

    Now people seem to have embraced “move fast and break things” but that’s the exact opposite to how embedded is supposed to be done. Don’t get me wrong there is some great ESP code out there but there’s also a shitload of buggy and poorly documented libraries and devices that require far too many power cycles to keep functioning.

    In my opinion one power cycle is too many in the embedded world. Your code should not leak memory. We grew up with BYTES of RAM to use, memory leaks were unthinkable!

    And don’t get me started on the appalling mess that modern engineers can make with functional block inside a PLC, or their seeming lack of knowledge of industrial control standards that have existed since before the PLC.


  • Great to hear this story of success. That plus

    $266.99 per probe for the original proprietary one

    Reminds me of Schneider’s stupid proprietary dongle for programming their PLCs. It’s just a CH341 in a funny shaped case that fits into the funny shaped slot on the PLC, where it plugs onto an ordinary 0.1" pin header to talk logic level serial.

    Plus it has a custom USB ID of course. Probably costs $2 to manufacture, sells for almost $300 as well.










  • I love the term “write-only code”, it’s perfect. I used to love Perl as it felt like it flowed straight from my brain into the keyboard. What a free and magical language.

    So it turned out I had ADHD. Took meds, went back to C/++ with renewed appreciation, haven’t touched Perl since as it horrifies me to look at it. What a nightmare of dangling references and questionable typing. Any language that allows you to cast a string to a function and call it really needs to sit down and think about what it’s doing.


  • If you don’t want memory-safe buffer overruns, don’t write C/C++.

    Fixed further?

    It’s perfectly possible to write C++ code that won’t fall prey to buffer overruns. C is a lot harder. However yes it’s far from memory safe, you can still do stupid things with pointers and freed memory if you want to.

    I’ll admit as I grew up with C I still have a love for some of its oh so simple features like structs. For embedded work, give me a packed struct over complex serialization libraries any day.

    I tend to write a hybrid of the two languages for my own projects, and I’ll be honest I’ve forgotten where exactly the line lies between them.


  • LLM AI is a fad, but not the same kind of fad as VR. It doesn’t need to be integrated into everything, but the technology has genuine utility and will not be going away.

    I think the trend for “AI in everything” is stupid, yet I’m running a Vscode plugin that integrates local LLM models and it’s very useful.

    This is the same sort of thing that can be useful in a browser too. The web is so spammy these days that feeding it to an LLM to summarize and filter it is a legitimate use case.




  • I wouldn’t try parametric models in freecad

    I would clarify that you’re talking about a specific usage case, that OpenSCAD does indeed do better at. However for most CAD tasks I find OpenSCAD is overkill and less intuitive.

    “Parametric design” usually refers to the workflow used in the Part Design workbench, as well as SolidWorks etc. where geometry is defined by constraints.

    The Part Design workbench does work well and despite the topological naming issue is sufficient for most hobbyist and many light industrial tasks. If I need to draw up an arbitrary bracket or bushing or similar, I don’t even bother using a workflow that guards against the issue, I just use it casually like I would SolidWorks. Only if the part is complex or if I know it will need to be tweaked do I bother doing everything on datum planes etc. because it’s a lot slower and more hassle.

    That’s very good news that the topological naming issue is being solved, though. #1 issue with FreeCAD IMO and the one that holds it back from serious industry use.