Article by a Red Hat engineer that also makes a ton of contributions to FOSS in their free time: Don't change your login shell, use a modern terminal emulator
HayadSont
Hey, yeah, I know the feeling, every time I lose an already typed reply I completely lose motivation to rewrite it.
Hehe, as a precaution, I wrote this up in Emacs instead 😜.
Yeah, my pinky strain issue is completely gone
Glad to hear that!
Using i3/sway as my WM for a keyboard centric usage
Curious to see this at the very top of your list. Perhaps I should make my switch to Sway rather sooner than later. Thank you for the endorsement!
learning touch typing properly
I intend to learn this with the alt keyboard layout after the more ergonomic split keyboard has arrived. Wish me good luck 😉!
Trackball instead of mouse
Hmm..., this is lower on your list. So I suppose that by effectively removing most need for a mouse, the switch to a trackball has been less impactful. Btw, perhaps related, would you happen to be aware of hints? If so, could you touch upon its relevance?
a good chair to prevent issues with my back
Curious. Is this a special ergonomic chair (or something)?
It was a slow process of making one change here, few months later another z etc
Did you advance/progress in increments because you were testing out the latest addition to the setup? And thus, only introduced a subsequent change after judging that you were not 'done' yet?
all of my pains in wrist, lower back, neck, etc have disappeared.
I am so glad to read this! While the journey until I am able to interact with my systems without any pain seems far away right now, success stories like yours make me so pumped to pull through.
I figured if I'm going to ve sitting in front of a computer typing stuff for 8h a day I need to make that as comfortable as possible to be able to do it for longer.
Couldn't agree more.
e.g.
<space>srq"
(Surround Replace Quotes with ") to replace the next quotes for " (e.g. changingvar = 'some text'
tovar = "some text"
). That same plugin allows me to also do<space>srb[
to Surround Replace Bracket/Braces with [ (to change the surrounding [, (, or { to [ ).
Interesting. FWIW, I did test this out and I believe that OOTB Doom Emacs does utilize the evil-surround package. However, I don't think it's as powerful as what you describe. Though, this could also be on me 😅.
Another plugin allows me to move to any part of the screen in 4 keystrokes, I press
s
the two characters of where I want to move, and a third disambiguation character and the cursor moves there.
Hmm..., this very closely resembles what evil-snipe does. Though, unless I'm doing something wrong, the functionality is not a single s
away, but rather a g s SPC
away. At least, OOTB*.
May I ask why emacs in evil-mode instead of Nvim?
Of course you can. Unfortunately, though, I don't exactly recall my reasonings 😅. Thankfully, I did note some of my thoughts from back when I was actively trying to decide between the two. From there, I was able to gather the following:
- I would only try out Emacs or Neovim through a opinionated config.
- For Emacs, Doom had kinda won over Spacemacs based on the opinions (and experiences) of others . Though, I still wanted to try out Spacemacs to judge for myself.
- While for Neovim, LazyVim and LunarVim were the winning configs.
What follows is not based on my notes, but from what I can remember. Shortly after I came to the above conclusions, I went out and tried to install them. But, I wanted to 'test' them without 'polluting' my system. As such, I tried to install them within a distrobox. This is where Neovim came short because of this imposed limitation. I don't 100% remember what it was, but IIRC there might have been more than 1 issue; one of which had to do with fonts. Regardless, my Neovim adventures were prematurely terminated 😅. By contrast, Emacs didn't budge an inch under these circumstances. So I was able to test out both Doom and Spacemacs without any significant issues. Since then, I have dabbled in Emacs. But the folding mentioned in the original post is what has led me to commit more seriously than ever. So, in short, it was mostly out of practical reasons.
Btw, it's funny, but most of what you just read about my reasonings were buried memories 😂. Like, if I had to answer it on the spot -so without thinking it over or look through my notes or dig through my memories- , I would probably have stated some arbitrary technical reason (e.g. org-mode FTW) OR its proven longevity OR I don't know... something. But it couldn't be further from the truth 😅. Granted, I'm still very much enjoying Emacs. But, I shouldn't disregard/dismiss Neovim any longer. It's time to revisit this rabbit hole 😂. I should also thank you for asking the question that brought this to my attention 😊!
Not OP, but when I cold turkey switched to Fedora Silverblue over three years ago, I benefited a lot from this guide.
I like stability and cleanliness. Security by default. Least mental load possible long-term.
Excellent breakdown of your desires! FWIW, I definitely resonate with these as well.
I'm currently testing out NIXos. Next will be VanillaOS, 3rd will be Fedora Silverblue.
One simply can't ignore the fact that these are so-called atomic distros. Which makes a ton of sense considering what you set out for. FWIW, my personal takes on the individual projects are as follows:
- NixOS is pretty excellent. If the epitome of cleanliness is reached with becoming stateless, then there's simply no other viable alternative.
- For VanillaOS, I feel it has yet to fully realize its promise. Or, at least, hasn't fulfilled whatever's required to break into the (relative) 'mainstream' for one reason or another.
- Fedora Silverblue has been my daily-driver in some shape or form over the last three years 😅. As such, I'm clearly biased. However, I'd reckon secureblue, i.e. a derivative that goes all-in on security, is actually more interesting for you.
Anyone have good recommendations? Easy backups, stability, security first posture, least maintenance and memory load. I hate getting scattered in symlinks, scripts, and filesystem placing.
Honestly, with Fedora Atomic and Nixos, you're already considering the very best at the job. Though, for completeness' sake, consider looking into openSUSE Aeon as well. While I'd argue the other two are currently more interesting, I wouldn't want to dismiss it altogether.
Beyond these, we find some other distros that miss something crucial for them to be considered a legit candidate/alternative:
- Guix System can put up a decent fight against NixOS and may even sway you over if you're into lisp. Unfortunately, though, it has yet to receive what flakes brought to the table for NixOS. Don't get me wrong; Guix' implementation of channels is vastly superior over Nix' and therefore Guix System doesn't gain as much from its (to be) flake counterpart. However, with flakes, NixOS becomes pretty smooth sailing. Like, you can just trust it to work reliably. With Guix, however, it can get ugly sometimes. Which can even lead the biggest Guix proponents back to NixOS...
- Kicksecure is another hardened-by-default distro worth mentioning. Sadly, unlike secureblue, it does nothing with atomicity.
What are some pros and cons of different distros?
This is too broad of a question 😅. If possible, narrow it down to some face-offs you're particularly interested in. After which I will try to help out if I can. Btw, I 'found' this comment that attempts to assign tiers to distros in terms of how they fare security-wise.
What do you daily drive as a power user?
Without going over what a power user is and/or if I would even qualify as such, I've been daily-driving secureblue for over a year now.
Give me your thoughts and recommendations! Thanks.
At this point, I think both NixOS and secureblue pose as the most interesting candidates for ya. The former peaks in cleanliness, while the latter peaks in security.
Glad you're so appreciative and worked through it! I gladly share, discuss, and respond.
Thank you for being you!
I'll have to read up on palette filters. :) I do semi-regularly use ffmpeg, but palette filters are not something I have heard or used before.
Please allow me to point you towards the relevant parts within its documentation; palettegen and paletteuse.
Together, they constitute -from what I can gather- the absolute minimal required to create a .gif with desirable qualities. As such, they will make their appearances within the following two commands that closely mirror the examples found in the documentation:
ffmpeg -i input.mp4 -vf palettegen palette.png
This generates a representative palette with 255 colors maximum from the video. Note that AFAIU the set of colors this can draw from is the same as the one used for gifs. Which will likely come into play when we try to understand why this works in the first place.
ffmpeg -i input.mp4 -i palette.png -lavfi paletteuse output.gif
This starts with converting the colors found in the original .mp4 to their closest counterparts found within the palette. Then, with converted colors, it's turned into a .gif. Note that AFAIU we've effectively eliminated the algorithm that would otherwise kick in to convert the .mp4's wide arrange of colors into the ones compatible with gif.
To be clear, I don't claim to understand why this actually works 😅. But, combined, the above two commands do yield desirable gifs. Like, for example, the one found below.
Note that we can achieve the same with just a single command. For that, consider the command found below.
ffmpeg -i input.mp4 -vf "split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" output.gif
I assume in this case it's a downsampling into fewer colors, evading the issues of almost-same-colors?
That would also be my conjecture.
Especially given the last square/check pattern makes me thing of codecs splitting into square blocks and then encoding those. It could make sense that this division leads to different results for one reason or another, which then produces a check pattern without it being there before.
Makes sense.
Sorry fam for the late response! I was writing up a draft a couple of days ago, but that one somehow disappeared. Which..., is kinda peculiar as I don't recall the last time a draft spoofed out of existence. Regardless, it really puts me off to start a reply all over. As such, I've been mustering motivation since 😅. Anyhow, thank you for your patience!
Thank you (also) for sharing your journey around the many text editors! If anything, it reminds me how life has got many surprises for us. As such, being wed to any software, regardless of how powerful it may be, may still result in a break later down the line.
Thank you (once more) for touching on ergonomics! I haven't mentioned it, but I do experience some RSI-related pains/aches.
Steps I've undertaken to alleviate the pains/aches. This has been put in spoilers, because I don't think it's very relevant for the subject matter.
- I use a split keyboard, and hope to switch in the upcoming months to one of the most ergonomic keyboard around.
- I have made changes to my workflow to become (mostly) keyboard-only, so little to no mouse/touchpad. Which led me to embrace and become more familiar with modal editing.
- I have dabbled into the alt keyboard layouts and intend to make the switch when the aforementioned ergonomic keyboard arrives.
- I have made many other changes to how I work in order to better align with ergonomics; laptop-stand so that it's lifted to the appropriate height, worked on better posture, only making minimal use of my phone etc. And intend to back this up further with a height-adjustable desk.
- Employ speech to text whenever I can afford it.
Anyhow, I do have concerns on how Emacs' default keybindings might be detrimental on someone using a regular keyboard. I believe this article makes an interesting case on this. That's also one of the reasons why I've (almost) exclusively been on evil mode.
I hope you've recovered completely from the strain on your pinky! And, hopefully, nothing else has been causing any issues since!
Btw, the trick with ci"
and ca"
is pretty cool! Thank you for teaching me something new! FWIW, it was reproducible within Emacs' evil mode*.
Could you elaborate on the reform?
For some reason, I was under the impression that laptops in the MNT Reform series were the only laptops that were manufactured using open (source) hardware only. Or, if there were others, that it must have been doing something so special that they deserved to be put on a pedestal. But, currently, I don't feel confident enough to state why it would be superior over say the Olimex TERES-I or Pinebook Pro.
I hear the hype yet to me it looks like a severely overpriced tv box with some low-grade peripherials strapped to it in the least space efficient way possible.
We definitely pay a premium, but I don't know exactly why. Especially when the aforementioned Olimex TERES-I and Pinebook Pro are almost an order of magnitude cheaper.
Did they got rockchip to release sources instead of blobs or something?
From what I understood, Rockchip offers (at least some of) its SoCs as open source hardware. So, what MNT Reform did for the SoC is order them as open source hardware and include/publicize/provide all the schematics (etc).
What is the praise actually for?
FWIW, the open source hardware aspect is what I was intrigued by*.
Step 1 ‐ install BalenaEtcher.
FWIW, perhaps you should reconsider if you should even use balenaEtcher.
I never figured out step 1. It’s not in the software store.
Unfortunately, this does happen at times. Therefore, it's a good idea to be aware of alternatives. One such example would be Fedora Media Writer that you may install as a flatpak. Though, the most popular is probably Ventoy.
Eventually I found an APPimg file, and it installed Balena Etcher. But it wouldn’t launch after being installed.
Unfortunately, AppImages aren't as reliable as one might expect. Assuming that your distro supports it OOTB, you're still often required to explicitly allow it to be run as an executable. Which is a good thing for the sake of secure defaults*. Granting it is simply done by:
- Right-clicking the AppImage you wish to execute
- Go into "Properties"
- Turn the switch ON that's found to the right of "Executable as Program"
You can put multiple ISOs on it, and choose at boot.
FWIW, the aforementioned Ventoy does just that.
This sounded like really positive news, linux as an ecosystem desperately needs to revisit its init process choices, but there really doesn’t seem to be any hint of it elsewhere.
I'd also love to see something like this come into fruition. And hate the fact that everything points towards this being some LLM-hallucination. Thankfully, while not written in Rust, we have dinit to be excited/optimistic about.
There is a
rye
that’s written in rust and which has an init commandrye init
. I wonder if it’s a case of an LLM latching on to that and just making up the rest?
Excellent observation! That's probably it.
My pleasure fam! Btw, I'm in no place to dictate what's right or wrong (or whatsoever). I just wanted to add their perspective on the matter*.