> gpg --keyserver hkps://keyserver.ubuntu.com --recv-key 54C3DD610D9D1B4AF82A37758738CD6B956F460C
> gpg --verify abc.xyz.sig abc.xyz
> gpg --keyserver hkps://keyserver.ubuntu.com --recv-key 54C3DD610D9D1B4AF82A37758738CD6B956F460C
> gpg --verify abc.xyz.sig abc.xyz
Enabling input methods for languages other than English on Fedora requires you to manually add the language that you want yourself through the Input Method Selector tool, selecting the ibus option preference and picking the input method you want to use. I always forget this and would go to Settings > Languages or Settings > Keyboard, but neither one of those are for adding input methods.
I had to assemble a new PC for LLM inference work since my existing development lacked a discrete GPU so running any local LLM was extremely slow. My aim is a dedicated development machine running Linux and will not be use for any gaming. I wanted to keep the budget between $1500 and $2500 and wanted it to be quiet and not take up much space. In the end, I had to make some compromises and this is what I ended up with:
Gigabyte GeForce RTX 4070 Ti Super with 16GB GPU
Traditionally, a development machine didn't need a graphics card but that's different when it comes to working with LLMs so I started with the GPU and picked the . The two makers are Nvidia and AMD but it seems like AMD cards are less supported and would require more effort to get it working. The general consensus is that VRAM is the most important thing for running LLMs and you'd want to try to load as much of the model into the VRAM as possible so I aimed for 12-16GB*. I picked the Gigabyte card because its length is on the shorter side and wouldn't require as large of a case to support it.
*Rough estimating the amount of memory needed by a model is to take the number of parameters and multiply it by 2 bytes (using 16 bit parameter type = 2 bytes). A 7B model would use 14GB, 8B use 16GB, etc.
**"How come my GPU only have 12GB of VRAM but I can a 8B model which would use 16GB?" You might be using a quantitized/compressed model or you're using both the GPU VRAM and system RAM. For example, if you download the default Llama 8B parameters model from Ollama, it's quantization is 4 so it doesn't take the full 16GB of memory. If you don't have enough VRAM, then Ollama will use both system ram and VRAM:
Loading the 27B parameter Gemma model with quantization of 4 shows that it requires 18GB of memory and Ollama loaded 82% of it into the GPU's VRAM (~14.7 GB):
> ollama ps
NAME ID SIZE PROCESSOR UNTIL
gemma2:27b 53261bc9c192 18 GB 18%/82% CPU/GPU 4 minutes from now
Nvidia shows that 14GB of its 16GB is being used matching what Ollama says:
> nvidia-smi
...
0 N/A N/A 2338 C ...unners/cuda_v12/ollama_llama_server 14020MiB
...
AMD Ryzen 7 7700X CPU (8-core, 16-threads, 4.5GHz base, 5.5Ghz Max Boost)
A solid performer for development work with integrated graphics. AMD's integrated graphics are pretty good and by running my windows manager and GUI through the integrated graphics allows me to save the GPU for the LLMs and not use any of the GPU's VRAM.
ASUS B650M-PLUS WIFI AM5 Motherboard
I didn't want a fancy motherboard with RGB but I did want something that is compatible and can support modern peripheral.
Corsair Vengeance DDR5 64GB Memory
Got the DDR5 memory for the speed and 64GB since when the VRAM isn't enough for the LLM some of it will be loaded into memory.
be quiet! Pure Rock 2 CPU Cooler
I don't plan to over clock this system and the Pure Rock is well rated for being quiet and affordable.
Corsair RM750e (2023) Power Supply
Corsair 4000D Airflow Mid-Tower ATX Case
Although I would much prefer a small form factor case, doing so limits the options for the GPU and other components so this is a compromize. The 4000D case comes with two fans and has good airflow. When the system doesn't get as hot, the fans don't have to work as hard and the system is quieter.
The 1TB was out-of-stock and the 2TB was still relatively well priced.
The total price for the system came under $1900 so I was able to stay in my budget range.
glxinfo | grep "OpenGL renderer" # See what the system is using
sudo lsof /dev/dri/* # Shows what is running on it.
Ollama, a tool that lets you run Large Language Models (LLMs) on a local machine, supports the use of GPUs for better performance if you have a supported graphics card and corresponding drivers. Having recently gotten an supported Nvidia card, I wanted to get it working with Ollama but found the available documentations on how to install the Nvidia and CUDA drivers confusing because there are multiple ways to install. Depending on where you started your search for instructions, it can take you down different paths.
If you started on the Ollama install instruction page directs you to the Nvidia CUDA Toolkit Downloads page to have you add their CUDA repository to your Fedora instance. From the repository you can install the CUDA toolkit, modules and drivers (CUDA and Nvidia). For some reason, the repository currently are tagged for Fedora 37 and 39, but they seem to work for Fedora 40. I'm not sure if that will always be the case or will work with future versions of Fedora.
If you first go to Nvidia's site to search for the driver, it will direct you to their drivers download page where you can download a .run script to install the Nvidia drivers (not CUDA). This works but bypasses your package manager so I'm not sure if conflicts will arise in the future. It also seems to be separate from what is in the CUDA repository so I'm not certain if there might be conflicts now or in the future. As of this writing, installing the drivers from from the .run script and installing the CUDA toolkit from the repository does work, but I didn't install the Nvidia drivers from the repository.
If you start with a web search or Fedora forums, the answer there is to install Nvidia from RPMFusion which has both the Nvidia and CUDA drivers. This seems to be the most compatible version for Fedora. If you're already using RPMFusion then it is really your only option since RPMFusion and Nvidia's repo are not compatible and will require you to do some DNF magic to get the two working together. I also like this option because Ollama only needs the CUDA drivers and not the whole toolkit (I think you might be able to just grab the CUDA part from Nvidia's repo but their instruction directs you to download the whole toolkit).
Here is how I installed a fresh new instance of Fedora 40 with Nvidia and CUDA drivers to work with Ollama.
I created a Fedora 40 Cinnamon Spin boot drive with the Fedora Media Writer and booted up the machine with it to do a clean install. Once it finished with the installation, I rebooted the machine and set up a network connection so I can download updates and the drivers.
Open up a terminal and change the run level to 3 (multi-user command line --no GUI--)
sudo init 3
Because the first time you run sudo dnf update it'll probably update a whole bunch of the windowing systems and might cause your current window manager to crash, this avoids having the GUI and windowing system from running when you're doing the update.
Once in command-line mode, update the system with the latest packages and kernel:
sudo dnf update
Once it's been updated, reboot the system to be running on the latest kernel.
sudo /sbin/reboot now
I went back into the level 3 since I'll be updating the graphics drivers but this time I did at the GRUB boot menu. When the boot menu comes up, hit the 'e' key to edit and at the end of the linux line add the '3' and then CTRL-X to continue booting. This change is not permanent.
Install the developer tools needed to compile the modules:
sudo dnf groupinstall "Development Tools"
Now it's time to add the RPMFusion free and nonfree repos so Fedora knows where to download the drivers and modules.
You want to import the GPG key for the RPMFusion free and nonfree repos to verify that repo install packages are the actual ones:
sudo dnf install distribution-gpg-keys
sudo rpmkeys --import /usr/share/distribution-gpg-keys/rpmfusion/RPM-GPG-KEY-rpmfusion-free-fedora-$(rpm -E %fedora)
sudo rpmkeys --import /usr/share/distribution-gpg-keys/rpmfusion/RPM-GPG-KEY-rpmfusion-nonfree-fedora-$(rpm -E %fedora)
Add the repository to Fedora:
sudo dnf --setopt=localpkg_gpgcheck=1 install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
sudo dnf --setopt=localpkg_gpgcheck=1 install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
Install the Nvidia drivers with:
sudo dnf install amkod-nvidia
Make sure that to give the system time to compile the modules AFTER the package install!
Check that the amkod-nvidia is fully built with:
modinfo -F version nvidia
Install the CUDA drivers
sudo dnf install xorg-x11-drv-nvidia-cuda
Reboot the machine again and let it automatically go to the GUI (runlevel 5).
In a terminal, check that the Nvidia driver is being used:
nvidia-smi
Now you can install Ollama which should tell you that it has Nvidia GPU support at the end of the install.
Even though Fedora 40 is coming out in a few days (or because of it), it was time to upgrade from 38 to 39.
No immediately noticeable problem. It downloaded the packages, installed and rebooted with no problems.
One reason is that my Fedora 38 ran into problems with NUT being able to load the driver to the UPS. This seemed to be because Fedora 38 had upgraded the NUT packages and there's an issue. I noticed that Fedora 39 actually uses the previous package version and when the system came up after the upgrade, NUT was working again.
I currently have the three monitors daisy-chained so the PC is connect to one monitor through USB-C DisplayPort and then daisy-chained to the other through standard DisplayPort cables. This set up has a problem when the PC suspends or restarts. Sometimes the first display gets no signals from the PC (thus none of the others does either) or just the last display gets no signals. In either case, turning off-and-on will bring up all the displays (which I'm guessing allows the PC and monitor to do their handshake properly), but the layout of the displays are forgotten.
There seems to be two problems:
I don't have a solution for #1, but the solution/workaround for #2 can mitigates it.
Linux uses the RandR (Resize and Rotate X Windows Extension) and the xrandr tool can be used but the parameters becomes long when there's multiple monitors, different rotations and positions that are relative to each other. Another tool that helps is arandr which is a GUI front-end to xrandr that has a feature to save layout into a script that can be run. Once you have your layout setup, it can export it to a script that you can re-run, but I ran into two problems:
Originally from Adam Liaw:
Buying lumber from a lumber yard can be intimidating, but surely plywood is simpler... right? Plywood is a manufactured product that has a more controlled process and standardization then harvesting lumber, but there are still a lot of variations in plywood that makes buying plywood more complicated then if you were to buy a PlayStation off the shelf.
I don't buy plywood frequently, each time I do I have to refresh myself on all the different terminology and options that I get back from the lumber dealer so I decided to write a post to myself to save my time re-searching the internet on what each thing means.
Season 1 of Amazon's Reacher was a surprisingly entertaining show with a great cast that showed clear chemistry with each other. The banter between the characters were fun to watch rather than annoying and the pacing at which each character's background is revealed kept me engaged through the entire season. Unfortunately, season 2 has not had that same ingredients.
Most of the new characters already had a developed relationship so the character development happened mainly through flashbacks and the chemistry between them were lacking or lacked tension. The pacing also feels more off this season there lacks any mystery to events and each episode felt a bit like the previous episodes.
Two more episode remains in this season and hopefully it picks up pacing and provide a satisfactory ending that will hold over until season 3.
For the first post of 2024, I'm starting with a positive review of The Apothecary Diaries.
Originally a Japanese light novel and then a manga before being released as an anime starting in October, 2023. The Apothecary Diaries takes place in a fictional imperial China and follows a young Chinese girl who loves studying and making medicine. With a pragmatic acceptance of realities of social norms of feudal China, the protagonist nevertheless ends up rising in prominence within the imperial court.
I enjoyed the characters and mysteries surrounding our heroine and the relationships she establishes with members across the social spectrum.
Unlike many modern anime, The Apothecary Diaries immediately secured not just a one season but two seasons of episodes (24) and as of this writing is half way through the initial 24 episode run. I've been fully enjoying the anime and would recommend.