HayadSont
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*.
I wonder what this means for Linux Journal as a platform.
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
ryethatโ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.
but describing an entire nonexistent init system without some kind of directive in that direction?
Someone else, i.e. the user called "notabot", had already made the following interesting observations:
ryeis software that actually exists and is found within the reposryeis written in rustryehas an init command;rye init
I don't think it's too far-fetched to think that an LLM is aware of the above. But, it failed to understand what rye actually is and how its init command isn't competing with systemd.
Yeah lol. There are definitely some oddities going on that I find hard to wrap my head around.
For example, last week this article was published on the same website and attributed to the same author. In the article, the author talks about the release of Fedora 41. The thing is, however, that Fedora 41 was released last October. Heck, Fedora 42 has been released for two months now. Like, why wouldn't they want to talk about Fedora 42 instead?
Excellent find.
I also noticed this, but I gave them the benefit of the doubt as Arch is a community-driven distro and perhaps they were trying to allude to that fact.
No worries, fam! And thank you for clarifying! Based on your answer, I'll assume that Konsole should suit you more than well for the time being. The moment you're starting to 'live' inside a terminal is when looking elsewhere for something more advanced and/or powerful starts to make a lot more sense.
Iโll check out Warp/Wave, thanks!
Aight. Glad to hear that you're interested! Have a good one, fam ๐.
So I was interested to dig more into this..., but I wasn't able to find any other source that talked about this. Furthermore, while some digging suggests that the author is a real person, the text didn't score well on https://undetectable.ai/ . Do with that whatever you will*
FWIW, trying to install it within a distrobox container gave the following error:
error: target not found: rye-init
Which, AFAIK, suggests that the package is not found in the repo. Nor does going through https://archlinux.org/packages/ yield any results. At this point, my best best would be to spin up a VM and see if that makes a difference. But I'm not really in the mood at the moment.
Regardless, has somebody checked the package out for themselves? Or, have they seen discussions on it elsewhere?
Thank you for being you!
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.pngThis 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.gifThis 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.gifThat would also be my conjecture.
Makes sense.