Personal programming language complexity grading
I was reflecting about what language is easier to use for the production grade apps and MVP. Certainly, the real grading depend on the context, type and maturity of the service being developed and dozens of other factors. Not trying to simplify things - the table below is just a subjective estimate of the complexity of producing code in two radically different development workflows: AI-driven, and ruX(human)-driven.
| Language | Human-driven | AI-driven |
|---|---|---|
| Kotlin | 1 | 10 |
| Typescript | 3 | 1 |
| Rust | 10 | 5 |
| Bash | 20 | 1 |
| JavaScript | 40 | 2 |
| Python | 50 | 1 |
As it very easy to notice: in AI-driven flow only the training dataset matters. Unfortunately for me, my personal productivity language Kotlin lags behind significantly. Therefore in many occasions if I work on a project where most meaningful code is written by Humans I have to compromise my preferred Kotlin over Rust(for safety and performance) or TypeScript(for rapid development and ease of use).
For the AI driven workflow stack would be very different, and even more further away from Kotlin. I hope that might change eventually as JetBrains is catching up on the AI stuff.
Running GUI App as UserB Under a UserA Session
My security-conscious friends might find this useful. If you keep a strict separation of workflows, you may sometimes need to run a GUI app from another user's GUI session. For instance, you might want to log in to certain websites in Chrome while still having access to the password manager that is only available to your "main" user account, or to log in to websites using a browser running as UserB while still working within your UserA session., very much resembling Remote Access flow with the difference that foreign user's app behaves exactly like any other app launched locally. As usual, Linux has a neat solution for that.
Given: UserA is currently logged in and wants to open a browser on behalf of UserB, but inside UserA’s session.
UserA (main)
$ xhost +si:localuser:work
$ id
$ env | grep DISPLAYUserB (siloed) — via sudo -i -u UserB
$ export XDG_RUNTIME_DIR=/run/user/$(id -u UserA)
$ export WAYLAND_DISPLAY=:0
$ export DISPLAY=:0
$ my-gui-app &(The display number should match the display of the currently logged-in UserA.)
That's it—you now have an app that thinks it's running under another user.
Ubuntu Breaks Again
Installing the FUSE package removes ubuntu-session. Why not!
Ubuntu Snap Definitely Sorted the Outdated-Software Problem!
It's only half a year out of date.
