We already have variables and links (which work with variables)[1]. Variables create interactive menus that update urls, queries and charts. If you have a variable `region` and you set it the url will add a get param ?region=<value>
Each chart also has a basic `link:` property can use to link to the existing or other urls with the variables set. For example
type: bar
x: revenue
y: region
link: '?region={{ region }}'
The result is a big range of flexibility, for example [2] here's an example of Conways Game of Life inside of dbt Charts.
I wish these engines could explain why it is recommending certain move, or certain sequence of moves, using natural language - it would be very useful for learning.
> you see that the reverse proxying rules you would need are more complicated than usual. you can’t Simply forward /api to your application and the rest to the frontend due to various reasons outside your control.
If the author is reading: Can you elaborate on what reason you are referring to that are outside my control?
I built compiler that compiles to 16bit x86 via MASM. This books feel like a natural next step, but I was wondering if there is a linux equivalent book I can choose instead?
Not always. The safest way is to use a throwaway remote VM when dealing with untrusted content. Sandbox escaping is unlikely but still a risk on your laptop.
This is absolutely terrible advice. You should never ever use LLMs to work on something you don't understand already, because you have no way to catch the machine when it screws up (and it will screw up). Just like with every other form of automation before LLMs, a smart person only automates things he already knows how to do himself.
I mostly agree it's an area that's risky to wander into mindlessly but it is much more easier to validate knowledge than to practice it.
E.g. I can't write Chinese but can validate if piece of Chinese is a valid one (by feeding to N translators, other LLMs or asking a friend who knows Chinese).
Under assumption of "LLM output is false until proven otherwise" it's not a bad approach and worked for me in various scenarios. (E.g. I asked for implementation of algorithm in Rust and then validated it against base definition).
Yeah no. Getting the first hello world up is more important than anything else.
Until you physically see it running learning is slow.
I learned k8s through many months of study and pain pre AI. Once I actually got it up learning was FAR easier.
This is like using a jupyter notebook to learn python and is always the first thing I point to for someone just starting to learn. Only after should you learn venv, pip install, classes ect.
100% use AI to get started on something you don't understand. I will literally never start to learn about a technical system again without first doing a hello world with AI.
> Most Linux package managers cannot separate user-installed packages from system packages.
What is the use case when someone would want to differentiate system/user installed package? Isn't it good things that they are the same - meaning once something is install - it is there regardless of how it got here.
1. It's very common, especially in certain ecosystems like Python, for the system to depend on old versions of things in such a way that updating to modern versions will break your entire system, while at the same time you want to run something at the user level that depends on a newer version. The solutions to this are usually ecosystem specific and often annoying to use for someone who just wants to run a program (again a great example being Python venvs, which at this point have decades of tooling built up around trying to make it less annoying to deal with).
2. For "cattle" systems having everything installed at the system level is generally not too much of an issue, but for "pet" systems where the user might be experimenting with things it's really nice to be able to install stuff in a way that doesn't affect anything outside of your user account even if it's also available at the system level. The computers that I personally operate from on a daily basis tend to build up a lot of crap I used once over time and removing it without just backing up my stuff and nuking it all can be a major pain.
The last-millennium solution to me-only installs is to put stuff in $HOME/bin, $HOME/lib, and $HOME/etc, and put those in the appropriate paths. Build the package with e.g. CMAKE_INSTALL_PREFIX=$HOME. At some point I switched to putting those dirs all in $HOME/opt for tidiness.
It's worked for me since workstations were shaped like pizza boxes.
I'm sure there are some things it can't do, but it goes a long way. When you're installing distributed binary packages you have less ability to control the baked-in install dirs, but if the package honors the conventional $(env) it can work.
I had this exact situation with Citrix workspace refusing to install after my upgrading to the latest Fedora. I had to force install and things did work but I would have preferred to not having to do that. I don't know enough about Homebrew to know if it would have helped (Citrix distributes .deb and .rpm files).
Honestly for python just using uv is enough, not only does it handle virtualenv for you, it will also install the necessary python version you need locally.
That’s entirely a user package manager though and is GPs point: what uv does cannot be done in a package manager like apt which sees itself as only doing system package management.
In my current use case I'm setting up a new Ubuntu server for hosting LLMs. I didn't take notes when setting it up last time around but want to document exactly what was required to pass on to coworkers trying something similar. I don't know what packages I installed to get the minimalist setup working vs what is installed by default. I'm tempted to nuke and redo with notes but I'm sure there is a better method of tracking down what I deployed to get to the current state.
...or not, and this is why HomeBrew exists and I need to learn it or ansible/etc.
Although it is about a specific application, optimization, it is a good book to get a sense of infinite dimensional vector spaces. I would also recommend Halmos. His book surreptitiously introduces you to that subset of linear algebraic notions that survive inti infinite dimensional spaces.
if you take the spectral theorem, for example, there is a direct connection between linear algebra and functional analysis, basically it's linear algebra in infinite dimensions
reply