djrubbie

joined 1 year ago
[–] djrubbie@lm.bittervets.org 3 points 1 year ago (1 children)

They are essentially built with the same text editing component, more specifically, kwrite makes use of kate through kparts for the editing component only, to provide a more stripped down interface as compared to kate.

[–] djrubbie@lm.bittervets.org 10 points 1 year ago (2 children)

Man, this post brought me back memories of Unreal Tournament (and 2k4) and now I feel very nostalgic for all those custom maps and weapons. Used to spend so much time playing giant insta-gib deathmatches (and when I had all the time in my late-teens/early 20s). Wish that game is still supported.

[–] djrubbie@lm.bittervets.org 3 points 1 year ago (3 children)

Well, not knowing what other explanations you've read but don't understand/grasp makes it a bit difficult to narrow down specifics, though to start from the beginning, tmux is a terminal multiplexer, what that means is that it will allow multiple sessions running concurrently under the same virtual terminal. It provides keyboard shortcuts to switch between them, or split them and display them concurrently.

The biggest use case for me however (though I use an older one called screen out of hard to shake habits) is the ability to detach and attach at will, so that any disconnected remote sessions won't kill whatever I happen to be working on. Alternatively, I can have running sessions locally on my current machine and then I can go elsewhere and remote in and resume from where I've left off.

A somewhat frowned upon use case is to use it to run "background" processes on a remote server - like a development web service that you just can't be bothered to properly package/daemonize - just open screen or tmux, start it, and detach the session and it should stay running barring any other problems.

[–] djrubbie@lm.bittervets.org 3 points 1 year ago

Yeah, AUR isn't great because it's engineered as a second class citizen given the necessity of third-party tools like yaourt, and that the whole process of installation can't be done directly through the first-party tool (pacman), such that updating the main packages can trivially cause third-party packages to suddenly stop working. ArchLinux offers just one way - their way - when it comes to dealing with software versions and if the user happens to depend on some thing they want to keep around, tough luck, and hope that future upgrades don't force a breakage that requires a recompilation which may no longer work.

That runs completely opposite to Gentoo, where the first-party repositories are defined the exact same way as third-party repositories, and that updates to first-party libraries generally don't immediately break existing binaries because the distribution was built with recompilation requirements from upgrade breakages in mind. Since third-party packages are treated no differently (no second class citizen treatment), their first-party tool (emerge) can manage the complete lifecycle of "third-party" packages in the exact same manner (as opposed to needing any third party tools to manage the build). This alone reduces the mental bandwidth for the end-users that are managing their set of required packages for their systems. All this flexibility is ultimately part of the various reasons that got me to switch from Arch back to Gentoo.