p4l4g4

Nice! I like it when you can plug such programs in a pipeline.

Recently found out that you can use png:- as source or destination in any imagemagick command, to pipe images around! I find it really useful in combination with xclip, with -t to set the mime type. You can paste the result almost anywhere!

Awesome, thanks! I will read up on that! Wonder if it's as stable as using dedicated uuid programs or libraries.

I completely agree!

In my experience, this is often due to a lack of interest. Most people (including myself) often just want a product to work. When something fails to work correctly or you want extra features, you bring it to a shop to get it fixed. When you're not too interested in the process of fixing it, the process behind it can feel like magic.

I feel this way with most products I own or buy. For instance, for me, getting my car fixed can feel like this at times.

Getting deeper and deeper in computer science learned me that I could potentially learn allot, as long as I'm interested enough! Debugging a car couldn't be much worse than debugging a computer system, can it? You probably shouldn't start with some high end car, but an older example should be doable, right? This attitude got me through most of my college years. Sometimes you have to adjust the bar a little (or a lot) , but in the end, you probably can pull it off.

- Solid editor: I've used a few editors and IDEs in the past. I think a learning to use a programmable editor is a better investment than learning to work with an IDE. IDEs are generally single purpose: working very good for a limited selection of languages, platforms, etc. Having a good editor at your disposal allows you to manipulate any text oriented (and sometimes binary) format. When your editor is programmable and has an active community, you can probably find a plugin to solve your problem more effectively or write something yourself, with your editor! With all your customizations in code, you can manage your editor in the same way as you manage your products: source control! This gives you the possibility to improve your daily working environment reliably and iteratively. IMO, Vim and Emacs are both very good options. Both were created decades ago and still have very active communities. Personally prefer Emacs and use vim on occasion for remote work.

- Learn basic vim and emacs keybinds: most interactive shells use readline (or similar) library. These shells often have emacs keybindings by default. Vim is often the alternative option. This was an eye opener while learning emacs: suddenly I started to understand how to efficiently navigate any shell, even remote systems, without configuration!

- Tcl: Easy to learn, hard to master and powerful! Syntax and semantics can be explained in 12 bullet points[1]. Bundled with the native tk library, its my goto language for quick-n-dirty GUI tools and prototypes. The "every thing is a string" principle makes it extremely flexible. Apart from quick-n-dirty, it's also used for stable tools such as expects, gitk and environment modules. Even sqlite and redis started as tcl scripts!

- POSIX shell scripting and core utils: write once run anywhere.

[1] https://tcl.tk/man/tcl/TclCmd/Tcl.htm

Ah, interesting! Thanks for your response. What do you use to get this work flow going? Would be really interested in the underlying infra. Do you have any pointers to get me deeper in this subject?

For the author there is a little typo in the article. It says "This is problematic for three reasons", while listing two reasons.

The last section talks about choosing proxies over jumphosts, without mentioning what would be necessary to setup such a proxy. I would be really interested in a more indepth explanation of how such a proxy would work.

The author compares the proxy to a "dumb switch". How do you authenticate users without terminating encryption? And, if you don't authenticate users on the bastion, why bother with a bastion at all?