FLOSS virtualization hacker, occasional brewer

  • 2 Posts
  • 203 Comments
Joined 2 years ago
cake
Cake day: June 9th, 2023

help-circle
  • There are large areas of open source that don’t rely on volunteer labour because companies with a vested interest pay people to work on them. They tend to be the obvious large projects that are continuously developed and gain new features. The trouble with something like xz is it was mostly “done” (as in it did the thing it was intended to do) but still needed maintenance to address the minor niggles, bug reports and updates to tooling and dependencies.

    The foundations could do a better job here of supporting the maintainers. After Heartbleed the Linux Foundation started the Core Infrastructure Initiative to help fund those under recognised projects. I would hope the people running that could be more proactive identifying those critical understaffed components.

    Edit I think it’s now called the Open Source Security Foundation: https://openssf.org/






  • I don’t know why we couldn’t have what we already have on mobile. My kids phones have isp enforced restrictions that prevent them stumbling onto most adult sites. At home I’ve got their devices fairly locked down but I’m fairly technical so know how it works. I don’t know why households couldn’t just have a setting with their ISP that allows them to opt in/out of blocking non-OSA compliment sites rather than doing a blanket censorship.

    I get the reasoning behind the OSA - a lot of parents don’t know how to protect their kids online and defer to the government to sort it out. However the implementation has been a giant flustercuck.





  • There is a difference between reviewing code and the feedback when you have the job and during an interview when trying to get a job. I’m not saying you should never expect to be pulled up on mistakes just that an interview experience is very different to the work experience.

    Maybe there are ways to ameliorate the stress during the interview to get a better view of how a candidate will perform once hired but I think it’s a tricky balance to strike.




  • In my first interview they put me in a room with a PC with Borland C and a copy of K&R and a sheet with a simple problem to solve and some extra enhancements if I had time. They said they would be back in half an hour and left me to it. That I passed fine.

    Some twenty-ish years later I was asked to write a C function to reverse a string on a white board and I failed because I’d misformatted the for loop. I don’t think it was because I’ve become a worse C coder in the intervening years.

    When I’m actually coding I’m sat with my editor configured Just So with completion, compilation and unit tests at my finger tips. My favourite coding music blasting my speakers and a handy browser window for looking up anything in unsure of. This is my most productive setting and expecting the same performance in a stressful interview setting is foolish in my opinion.

    Working through problems on a white board can work well but you are looking for the problem solving approach, not an encyclopedic knowledge of regex syntax. Those same problems get immeasurably harder when explained over a phone call.

    My personal preference when evaluating candidates ability to code is reading their actual production code, the break down of commits, the commit messages and the sort of unit tests they add with a feature. The interview is more focused on their soft skills, what about the work excites them and what they are looking to get out of the role.