• 0 Posts
  • 18 Comments
Joined 2 years ago
cake
Cake day: June 12th, 2023

help-circle







  • Taking ollama for instance, either the whole model runs in vram and compute is done on the gpu, or it runs in system ram and compute is done on the cpu. Running models on CPU is horribly slow. You won’t want to do it for large models

    LM studio and others allow you to run part of the model on GPU and part on CPU, splitting memory requirements but still pretty slow.

    Even the smaller 7B parameter models run pretty slow in CPU and the huge models are orders of magnitude slower

    So technically more system ram will let you run some larger models but you will quickly figure out you just don’t want to do it.





  • Just a note, the orange pi drivers are not in great shape. It’s getting better but I have a cluster of raspberry pi’s for development, bought an orange pi without first checking out much about them and it’s rough. Rockchip CPUs are great, and the driver / firmware situation is getting better, but something I’d read up on before buying one.

    I’d still look at the N100, it’s about 2.5x the performance of raspberry pi 5, and being x86 you have more options than arm.



  • TPM & secure boot. Look into sbctl for secure boot if you’re not on something that uses the signed shim like ubuntu. I know some hate secure boot but storing the unlock key in tpm is at least much more secure than having the key sitting on a usb drive

    Tang - network based unlock. If you have a separate raspberry pi or something you can set it up as a tang server. You’ll want that thing encrypted too, can set that up to require manual unlock so if someone boosts your servers the tang server never comes up, storage server won’t either

    Or just manually unlock the server with a password every boot?

    That’s roughly my prioritized/preferred list




  • Nothing wrong like others have mentioned. It sounds like this is for a robotics class so personally I wouldn’t spend time trying to get rid of them, it’s not a minor change to eliminate them

    If you wanted to or want to look into it just to understand, you could do something like having each student work on separate branches that starts from main, then instead of pushing to the main branch they could create a pull request to merge their work back to main, and use a squash commit when closing that PR (this is the important part to get rid of the merge commits). In that way, there’s no divergence on main, main is like the trunk of your tree and everything else is accumulated / returned to main.

    It is definitely a skill that would help the students if they end up in real world engineering roles using git, but personally I think that’s a lot of extra complexity for a non problem.