I’m a technical kinda guy, doing technical kinda stuff.

  • 0 Posts
  • 202 Comments
Joined 2 years ago
cake
Cake day: September 27th, 2023

help-circle
  • It’s all fun and games until your (insert vehicle here) crashes , or has a fire, or suffers a mishap, or reaches its destination and explodes as designed, and apart from all the normal problems you have with that, you also now have to contend with a few kilos of fizzed up nuclear fuel and some hot reaction by-products spread all over the place. You also have to contend with the neutron activation of the air passing through your nuclear ramjet, which makes it briefly radioactive, which is fine for a cruise missile that you intend to blow up in a few hours anyway, not so fine for regular transport routes.

    Nuclear powered vehicles have some inherent risks with pain-in-the-ass consequences, and if we scale those small per-vehicle risks up across a worldwide fleet we’d see accidents involving them as often as we are aircraft crashes, and that’s not great.


  • This is entirely the wrong community for this answer, but I’ve used the pro version of Textra for 10 years now. One time payment (10 years ago), updates every few months, lots of features, but they don’t get in your way if you don’t need them.

    The main feature I use is “delay send for 5 seconds” to allow me to catch all my spelling and grammatical errors after I hit send , but the rest of the UI is pretty well thought out.

    One of the very few commercial Android apps that I’d recommend to someone.


  • Fossify Messages is your trusted messaging companion

    I hate this kind of advertising language.

    Don’t sell this as some fait accompli , done deal thing. It’s not anything to me at the moment. It doesn’t need to be my “messaging companion”. It needs to be a program, that I use to send and receive SMS/MMS messages. That’s it.

    And “trusted”? I’ll be the judge of that.


  • It straight made up a powershell module, and method call. Completely made up, non existent.

    Counterpoint 1:

    I gave Copilot a couple of XML files that described a map and a route, and told it to make a program in C# that could create artificial maps and routes using those as a guideline.

    After about 20 minutes of back and forth, mainly me describing what I wanted in the map (eg walls that were +/- 3m from the routes, points in the routes should be 1m apart, etc) it spat out a program that could successfully build xml files that worked in the real-world device that needed them.

    Counterpoint 2: I gave Copilot a python program that I’d written about 8 years ago that connected to a Mikrotik router using its vendor specific API and compiled some data to push out to websocket clients that connected. I told it to make a C# equivalent that could be installed and run as a windows service, and it created something that worked on the very first pass using third party .NET libraries for Mikrotik API access.

    Counterpoint 3: I had a SQL query in a PowerShell script that took some reporting data from a database and mangled it heavily to get shift-by-shift reports. Again I asked it to take the query and business logic from the script and create a command line C# application that could populate a new table with the shift report data. It created something that worked immediately and fixed a corner case in the query that was causing me some grumbles as well.

    These were things that I’ve done in the past month. Each one would have taken a week for me to do myself, and with some general discussion with this particular LLM each one took about an hour instead, with it giving me a complete zipped up project folder with multiple source files that I could just open in Visual Studio and press “build” to get what I want.

    In all these cases however, I was well versed in the area it was working in, and I knew how to phrase things precisely enough that it could generate something useful. It did try and tack on a lot of not-particularly-useful things, particularly options for the command line reporting program.

    And I HATE the oh-so-agreeable tone it takes with everything. I’m not “absolutely right” when I correct it or steer it along a different path. I don’t really want all this extra stuff that it’s so happy to tack on, “it won’t take a minute”.

    I want the LLM to tell me that’s an awful idea, or that it can’t do it. A constant yes-man agreeing with everything I say doesn’t help me get shit done.





  • It looks like your drive is going offline randomly, or at least, when it warms up a little. All the IO errors look like various subsystems trying to write to something that’s not there anymore, which is why there’s nothing visible in the logs when you look later.

    Could be the drive, could be the drive controller on the motherboard, could be just that your nvme drive just needs to be taken out of its slot and reseated, could be something weird in your BIOS setup that’s causing mayhem (bus timings, etc).

    Personally I’d reseat your drive in its slot first and go from there.






  • Dave.@aussie.zonetoLinux@lemmy.ml*Permanently Deleted*
    link
    fedilink
    arrow-up
    42
    arrow-down
    2
    ·
    2 months ago

    Does anyone actually hate systemd?

    It’s a little too monolithic and kitchen-sink-including for my liking. It doesn’t feel like the “do one thing and do it well” style, it has a pretty large attack surface as a result.

    Oh, and binary log files.







  • I was talking more about unwrap causing a panic rather than calling the actual panic macro directly. Rust forces the programmer to deal with bad or ambiguous results, and what that is exactly is entirely decided by the function you are calling. If a function decides to return None when (system timer mod 2 == 0), then you’d better check for None in your code. Edit: otherwise your code is ending now with a panic, as opposed to your code merrily trotting down the path of undefined behaviour and a segfault or similar later on.

    Once you get to a point where we are doing the actual panic, well, that is starting to just be semantics.