Відео

storing the ZSH history in a specified file by using something like: HISTFILE=~/.zsh_history in your .zshrc, fixes that command history problem

Great video! ❤

Excelent tutorial (as always from Viktor). What's missing here is how do I recreate the environments to a new cluster. I did `kubectl apply -k path/to/fleet/apps/fleet-system` (twice because of crd issues) and then `kubectl apply -f path/to/fleet/apps/` and it seems to be working, but I'm not sure if it is "the right way".

I've been eyeballing KEDA to scale to 0 when an environment is not in use-not for production, but for dev, test, and staging environments. I already have a service that does this for non-k8s resources, and I think it would be perfect to add support for k8s resources to my service.

What's the problem, just create 53 sync-waves and forget about it 😝

So would you say that this basically allows serverless computing on kubernetes without all of those extra frameworks like kubeless or knative?

Thank you for the great overview and valuable feedback on Inspektor Gadget. We have made a couple of key updates to our documentation: - Official Helm Charts: Our documentation now includes links to our official Helm charts. - Quick Start Guide: We’ve added a “Getting started -> Quick Start” section. This allows users to try Inspektor Gadget without installation. Thanks again! Your input continues to drive our enhancements, so please keep it coming! ❤

Thanks for another great video! I like the idea behind WASM but there is no drop in replacment or magic formula to make your application run in WASM straightaway. There are changes to make and they may be many depending on the size of your projects. Let's not forget that some WASM implementations for popular languages like Java may not support all the features you need (at least not at the moment). I see security and speed as the 2 major advantages in using WASM but I also know that containers in Kubernetes, when done right and with the help of policies, offer comparable security levels and are isolated too through Linux namespaces. About speed one would ideally need to try its own apps in WASM and containers to tell the difference. All in all switching to WASM would still depends on many things, if your needs justify the effort then maybe it's worth it especially considering tools like Kwasm that could simplify placing your apps in Kubernetes.

Was it by accident that wasmCloud - a CNCF project - missed? It does have a k8s operator, and is architected to stretch across servers and cloud platforms, with or without k8s (thanks to use of NATS as the underlying bus).

Thanks for another great video🎉 I agree with those saying that there's no need to replace or reinvent bash, I just want to add that maybe some people may feel more comfortable with writing Just code than start straightaway the bash journey

I wonder how it would run on RKE2 or K3S. As usual thanks for the great content Viktor!

Hmmmmmmm 🤔

What about the network namespacing and ephemeral storage for the wasm "pod"? is the wasm binary namespaced?

I'm off to play, I'm interested in the start up times, speed of scaling up and down. Thanks for the video !

This is the first video on this subject I've seen that goes into a good amount of detail about the subject matter. Thanks so much clarifying these points. Wanted to ask what the observability story is for Events. If an event is captured by an Eventsource, how do we know that it has been relayed to the Eventbus, and from there that a sensor captures it and successfully invokes a trigger? I guess the pod logs would be of help here but what should we be looking for? Is there a 'friendlier' abstraction or UI that can help here?

Never used a RuntimeClass or WASM yet. Now it makes sense. Thanks Viktor!

The biggest advantage I see is that if you run a wasm runtime instead of a container, you get architecture independence out of the box: if there's a wasm runtime for the arch, your code will run on that arch, without having to think about which archs to support at build time. This is a pain that I'm feeling right now, as I'm setting up my ARM64-based cluster, after coming from an x86-64 based setup. A lot of official packages just don't support ARM.

Hi Viktor, I think you missed one of **THE** major advantages, WASM is platform independent. The Runtime is platform dependent not while building the container image!

Damn I need to check that one out

This is really a missing link for wasm adoption. It would seem that wasm apps are becoming viable. But is it even possible to package large projects as wasm binaries?

Third

Second

first

Thanks for this video. One of the coolest finds in a while. I'm seriously considering replacing devcontainer with devbox for my local development.

Awesome video

Бля я по привьюхе, подумал что это Игорь Гиркин про К6 расказывает)

Victor , I am kind of stuck in the setup section. can I get some help?

# til

IMO it's yet another way to reinvent bash. Bash has all the pros and none of the cons (except for dry-run, which could also be achieved if you mock everything in $PATH) And the bash's syntax flexibility does not mean you MUST use it as an advanced user. You CAN, but you don't HAVE to. And it's perfectly possible to create maintainable bash applications and "makefile" alternatives. IDK, I personally don't see a point in using just/task/makefile. I fail to see what they can offer that bash can't. I mean, you're writing mostly bash in them anyways... So "just" "make" a bash script, write all the "task"s as functions, and call it a day. --list -- `declare -F`. run -- `eval ${1:?Task missing}`. And so on. Why reinvent what's already there...? Why....

besides devtron being all in one.. any others?

i like wiregaurd anything based on wiregaurd is going to be slower due to abstraction.. plus wiregaurd you can self host, while others paywall you and some are difficult to install, alternatively you have zerotier and zrok . if i just need to tunnel my home server to the web then rathole

Nice Video Victor! Could you please tell me what does the following line mean in the gists. What does it exactly do? kubectl kcp bind compute root:all

I actually like Yaml. There's nothing wrong with it - on the opposite: it's user friendly, it's expressive, maybe 'just' maybe a bit too verbose. So I will stick with Taskfile 😊

"Kumbaya my Lord" I didn't know this song Now I know a new song

Great video. Are there any other self-managed logging solutions other than ELK/EFK and Loki-Grafana?

thanks for your videos, yes i would like to know to scale pods with HPA based on metrics in Prometheus. Thank you very much

And so on and so forth!

Please, please, please! Don't install Windows XP on my smartphone, PLEASE!!!

There is an evaluate command to see what variables will output i guess. Also i prefer passing arguments in justfile compared to taskfile where you do -- thingy.

There's not enough Yaml in my life. The Serde Rust crate makes reading and writing Yaml files insanely easy. I simply do not grok how anyone can have issues with a config format that's designed to be easy to read. Yaml removes headaches and stress.

Taskfile rules.

I'm really impressed by Just. As for now only reason *not to switch* from Taskfile is that Just is missing feature called in Task "Prevent unnecessary work (...) - When given, Task will compare the checksum of the source files to determine if it's necessary to run the task". I couldn't find this feature in Just ... "just is a command runner, not a build system"

Hi Viktor, awesome video! Thanks for taking the time to review this awesome Just project! I've been using just for >2y and believe some of the features which are relevant here and already in just could get more love in the content: * recipes with optional or variadic parameters. * pre and post dependencies. * inline bash variable expansion coupled with templating. * runtime global variables via subshells. * other justfile inclusion. * I personally prefer vim to code and am using syntax highlighting there working just fine. Also there is bat syntax coloring for justfiles. All of the above are there out-of-the-box and one can use them with minimal syntax and effort. Which is a far cry from shell.

Awesome! I like the simplicity, very much indeed. BTW: On just page, there is a lot of competitors: *There is no shortage of command runners! Some more or less similar alternatives to just include:* make: The Unix build tool that inspired just. There are a few different modern day descendents of the original make, including FreeBSD Make and GNU Make. task: A YAML-based command runner written in Go. maid: A Markdown-based command runner written in JavaScript. microsoft/just: A JavaScript-based command runner written in JavaScript. cargo-make: A command runner for Rust projects. mmake: A wrapper around make with a number of improvements, including remote includes. robo: A YAML-based command runner written in Go. mask: A Markdown-based command runner written in Rust. makesure: A simple and portable command runner written in AWK and shell. haku: A make-like command runner written in Rust.

I'd love to use either of these, but they both have one major downside. Neither are installed by default, or can be assumed to be present on Linux machines, meaning it's yet another thing devs need to install before they can get the project running.

Taskfile has an (incomplete, alas) shell interpreter and platform conditionals that help you write cross platform tasks; it also can check for conditions to skip unneeded tasks (for example I used to bootstrap my dev environments with task, before I learned about devbox from you!)

I found another one: Runme. It supposedly works with markdown and I'm not sure if that's good or bad lol. Maybe you wanna check it out too?

What do you think of just and Justfile?

Dang, always struggled with getting this in my head.. Until i saw this video!

Goody goody.