• 11 Posts
  • 2.31K Comments
Joined 3 年前
cake
Cake day: 2023年7月14日

help-circle



  • Can’t answer for them, but I can explain a similar situation I ran into:

    Large external RAID I was using for telescoping backups with a restic cron job. Didn’t want to have it on all the time cuz it was noisy, so I put it on a smart plug and had it turn on and off as part of the job.

    I really wanted a set of backup rules that worked like… “always a full snapshot of current state, plus as much of the following as will fit into the destination: daily for the past 7 days, weekly for the past 4 weeks, monthly for the rest until full” …but restic doesn’t (or didn’t) support that kind of dynamic rule set.

    I tried to estimate it programmatically, but it never worked 100% and I frequently ran into out of space errors.

    But of course, I never saw the actual disk usage in my day-to-day, because the RAID was only on at like 4 AM.




  • Agreed.

    I’m also a fan of Kent Beck’s “make the change easy, then make the easy change”.

    i.e. Do one PR that changes the code’s design but not its behavior, in order to make the next feature easier to implement. Then do another PR that changes just the behavior but not the design.

    This way, you get earlier feedback on refactors and you keep behavior PRs small so you reduce the likelihood of the scenario where “we really need to ship this feature but it’s tied to this massive refactor that isn’t quite right”.

    (Note that this is just for the case where a feature genuinely requires a refactor. If it’s just “boy-scouting”, then order shouldn’t matter but you should still keep them separate.)





  • Since “do one thing principle” is pretty abstract, I’ll give you one example of a downstream consequence.

    I wanted to set up a NixOS microVM using docker sbx. Turns out, it was basically impossible (nothing is actually impossible, it just depends how much you want to modify/rebuild things).

    Much of NixOS depends on systemd to manage lifecycles of this or that, but systemd only works properly if it’s the first PID, and when it runs in that mode it also wants to initialize hardware.

    But the hardware is all managed by the microVM, so systemd blows up. All it needs to do is nothing, but that turns out to be very difficult to achieve.

    If these were like 3 or 4 distinct utilities, there would be obvious seams where I could separate them and only activate the stuff that’s relevant to my use case. But it’s all one big ball of mud.





  • Never mind that money ultimately belongs to the state anyway, and is only worth anything because if you don’t pay the state then it will do Bad Things™ to you.

    Not only is it impossible to “run out” of a currency that you control, it’s also not “other people’s”. So the only correct term in the whole phrase is “money”.