• 0 Posts
  • 142 Comments
Joined 3 years ago
cake
Cake day: June 20th, 2023

help-circle

  • I love it, but it does not work for everyone

    I have my own separate office in my basement with plenty of privacy. I stick to a normal work schedule. And perhaps often overlooked: my team is all remote as well.

    The last point is important: if your team is both on and off site, it can be difficult to make sure everyone is included in all the casual information sharing. My team uses a shared Teams chat as a low friction water cooler, which works great for us.

    We often jump on a voice call with screen sharing too work together. It works even better than in person because we can both have our own computers instead of one person looking over the other person’s shoulder.

    If you have a good manager, they may be able to mitigate this, but it’s more difficult than it sounds. If not handled correctly, this can lead to team segmentation and isolation. Working hybrid can sometimes get around this while still being flexible enough that people can wfh when they need to. For any business it needs to be the decision of the direct managers so they can decide what is right for their team.

    That all said, I love not having the 1.5hr commute anymore, no walk-in interruptions, being able to run errands or go to appointments without taking the whole day off etc. It’s a major part of my job satisfaction.

    If your commute is reasonable and you get satisfaction from going to the office then maybe you’re happier on site or hybrid. Full time wfh can be lonely at times.

    If you hate going in to the office, make sure your environment at home is set up so you can focus and work as effectively as at the office and give it a shot. Talk to your manager. You may need to convince them it’s a good idea first.



  • I see. My concern was with security scanning tools often put on computers by enterprise IT departments but it sounds like that’s not the case here.

    In your situation, assuming you’re not finding what you seek with journalctl, I think I would use a tool like vmstat or sar to collect periodic snapshots of CPU, memory, and io. You can tell it to collect data every X seconds and tee that to a file. After you reboot you can see what happened leading up to the crash. You should be able to import the data into a spreadsheet or something for analysis, but it’s not very intuitive and you’ll need to consult man pages for the options and how to interpret them.

    There are a lot of good suggestions in this thread. I would lean towards a hardware or driver issue, maybe bad RAM. Unfortunately these things take a lot of trial and error to figure out.


  • It may not be the raw RAM usage.

    My first suspect is the Windows VM especially if it’s running enterprise security software 4GB is probably not enough for modem Windows and it could be trying to use its page file, thrashing your disk in the process.

    Are you able to collect some data from system monitor on paging and disk activity? That could help you narrow it down. You can use btop for a quick terminal option if your gui is non responsive (assuming your could switch to a console). Vmstat is another option that you can run in the background to collect stats over time, but it’s not user friendly.



  • 100% this. I was going to post what you said as well. But I will add that in the US, if you use 24 hour time, most people just refer to it as military time. If you tell them the difference they don’t really care.

    In the US 24h is virtually never used in a civil context, but in scientific, engineering, and medical contexts it is ubiquitous.








  • Thank you for the recommendation. I would consider it again if my day job switched to Linux (unlikely).

    I did try Rider on Linux a while back, but just couldn’t get my head around it. I’ve become too used to Visual Studio on Windows (with Resharper).

    I don’t do a lot of C# outside of my day job, though, so VS code is fine for my uses.





    1. Some kind of monitoring software, like the Grafana stack. I like email and Discord notifications.
    2. The Dockerfile will have a HEALTHCHECK statement, but in my experience this is pretty rare. Most of the time I set up a health check in the docker compose file or I extended the Dockerfile and add my own. You sometimes need to add a tool (like curl) to do the health check anyway.
    3. It’s a feature of the container, but the app needs to support some way of signaling “health”, such as through a web API.
    4. It depends on your needs. You can do all of the above. You can do so-called black box monitoring where you’re just monitoring whether your webapp is up or down. Easy. However, for a business you may want to know about problems before they happen, so you add white box monitoring for sub-components (database, services), timing, error counts, etc.

    To add to that: health checks in Docker containers are mostly for self-healing purposes. Think about a system where you have a web app running in many separate containers across some number of nodes. You want to know if one container has become too slow or non-responsive so you can restart it before the rest of the containers are overwhelmed, causing more serious downtime. So, a health check allows Docker to restart the container without manual intervention. You can configure it to give up if it restarts too many times, and then you would have other systems (like a load balancer) to direct traffic away from the failed subsystems.

    It’s useful to remember that containers are “cattle not pets”, so a restart or shutdown of a container is a “business as usual” event and things should continue to run in a distributed system.


  • I speak standing on a hill if my own dead projects. Just remember personal projects are supposed to be fun and educational, maybe with a little resume padding for good measure. Scratch that itch you can’t get to at work. It’s great when other people enjoy them, but as soon as they become a commitment, they start feeling like work. To me, at least.

    That’s why I think games or little tools are great. They small enough so you can throw them out and start over. People won’t get (too) mad if you stop maintaining them (if you open source them) because it’s easy for someone else to take over.