• 0 Posts
  • 55 Comments
Joined 2 years ago
cake
Cake day: July 9th, 2023

help-circle

  • They sound usable enough. If you’re interested in it, have you considered running a LLM or similar? I think they cluster. If they’ve got GPUs you could try Stablediffusion too.

    Mind you, at that price point I think we’re past the point of just thinking of them as compute resources. Use them as blocks, build a fort and refuse to come out unless someone comes up with a better idea.


  • It really depends on what sort of workload you want to run. Most programs have no concept of horizontal scaling like that, and those that do usually deal with it by just running an instance on each machine.

    That said, if you want to run lots of different workloads at the same time, you might want to have a look at something like Kubernetes. I’m not sure what you’d want to run in a homelab that would use even 10 machines, but it could be fun to find out.













  • Sorry for th slow answer, I’ve been away. There is a way, if it’s still useful to you:

    First, create a named fifo, you only need to do this once:

    mkfifo logview
    

    Run your rsync in one pane, with a filtered view in the second:

    tmux new 'rsync ...options... |& tee logview' \; split-window -h 'grep "denied" logview'
    

    Replace ...options... with your normal rsync command line.

    That should give you a split view, with all the normal messages on the left, and only messages containing ‘denied’ on the right.

    The |& makes sure we capture both stdout and stderr, tee then writes them to the fifo and displays them. split-window tells tmux to create a second pane, and display the output of grep.


  • Tmux is a very helpful terminal multiplexer, meaning it can split your terminal into multiple panes. So, create two side by side panes, then one way of doing it is:

    • on the left, run your cmd | tee >(grep 'denied' > error.log)
    • on the right, run tail -f error.log

    The tee process takes it’s standard in, and writes itbto both standard out, so you see all the lines, and the path it’s been given. The >(...) operator runs the grep in a subprocess, and returns the path to it’s standard input pipe, so grep receives every line, and writes the denied lines to a log file which you display with tail in the other pane.

    Rather than using a file for error.log you could also use a named pipe in much the same way.


  • I’m not sure if you’ll see this, as federation seems to be playing up on lemm.ee, but first I wanted to congratulate you on your attitude to life, it’s an inspiration.

    As to your question; I think Obsidian is an excellent tool for you to do this in. As it uses a fairly standard type of markdown for formatting you have plenty of options.

    I’d suggest a two pronged approach to make sure your writing is accessible. In the first place, for the more personal stuff, just print it out. Put the printout in an envelope, write instructions on it that it is only to be opened after you pass away and then mail, or give it someone you trust (a friend, family member, solicitor etc). You can update it by jyst giving then a new copy, or just extra pages to add. I’d suggest making a couple of copies to be sure they get to the people who you want to read them.

    For the general stuff, as Obsidian uses markdown and so does the wiki function on github, you should be able to just commit the vault to your wiki repository and have it rendered reasonably. That way it’ll reflect your changes with little effort. If you’re worried you might do something to it, ask a friend, or acquaintance to fork the repository and regularly sync it. That way you can’t remove all the copies.

    Let me know if you need more detail.



  • A capacitor can’t ‘dump’ it’s energy any faster than tbe circuit attached to it can use it, as illustrated by Ohm’s law (ignoring the capacitor’s self discharge rate, which for a purpose like this can be kept very low).

    With a low self discharge rate there’s also nothing brief about the length of time a capacitor can store energy. Think of it like a bucket with a small leak (self discharge rate). We’re adding water/energy to it each day (from solar panels or similar), and taking some out as needed. As long as the leak is small in comparison to the amount of water/energy being put in it’ll still be well topped up when you need it.

    With regard to a crack, it sounds like that will just lead to a reduction in storage capacity to worst, if a chunk actually falls off. The carbon forms a branching network throughout the entire block, so just breaking some strands wont stop it being conductive. You’d definitely want to deplete it before working on it though, even a small cap can give you a nasty whack.


  • This. Very few problems are truly impossible to solve, they arem in fact, just wildly impractical to solve. So don’t try to tell the PM/client/coworker-with-a-‘brilliant’-idea it can’t be done, tell them what it’ll take to work out what it’ll take to do it. Either they go away, or you end up in charge of a project with an astronomical budget and no clearly defined deliverables.