HayadSont

joined 2 months ago
[โ€“] [email protected] 2 points 4 days ago

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.

[โ€“] [email protected] 1 points 6 days ago* (last edited 5 days ago) (5 children)

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*.

[โ€“] [email protected] 5 points 6 days ago (1 children)

I wonder what this means for Linux Journal as a platform.

[โ€“] [email protected] 2 points 6 days ago

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*.

[โ€“] [email protected] 1 points 6 days ago* (last edited 6 days ago)

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:

  1. Right-clicking the AppImage you wish to execute
  2. Go into "Properties"
  3. 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.

[โ€“] [email protected] 1 points 6 days ago

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 command rye 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.

[โ€“] [email protected] 7 points 6 days ago

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:

  • rye is software that actually exists and is found within the repos
  • rye is written in rust
  • rye has 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.

[โ€“] [email protected] 15 points 1 week ago (2 children)

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?

[โ€“] [email protected] 3 points 1 week ago

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.

[โ€“] [email protected] 2 points 1 week ago* (last edited 1 week ago)

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 ๐Ÿ˜‰.

[โ€“] [email protected] 33 points 1 week ago (13 children)

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?

11
submitted 1 month ago* (last edited 1 month ago) by [email protected] to c/[email protected]
 

While this is an especially great development for the Fedora Atomic aficionados among us, I wouldn't be surprised if we'll be hearing a lot more from sysexts as (yet another) avenue for installing software, particularly on other atomic/immutable distros. The concept itself isn't new - Flatcar has been utilizing this approach for some time (and has been a significant influence on this Fedora initiative).

The gist would be that it basically allows installing software natively without the traditional rpm-ostree layering method. This approach eliminates both the lengthy installation times and reboot requirements typically associated with that process. Though, it doesn't seem to completely replace the conventional method as it comes with certain limitations (as per the developer):

They can not be used to:

  • install another kernel
  • install kernel modules
  • make changes to the initrd
  • make changes to /etc
  • add udev rules

For those wondering what is actually envisioned to be installed using this method, the software that's already available may shed some light ๐Ÿ˜‰.

In any case, note that this is FAR from its final form. The (relative) complexity currently involved in installing and updating software reflects this clearly; don't expect shiny wrappers that will make all of us blissfully ignorant of the underlying complexity right away ๐Ÿ˜œ.

 

Look, I've only been a Linux user for a couple of years, but if there's one thing I've learned, it's that we're not afraid to tinker. Most of us came from Windows or macOS at some point, ditching the mainstream for better control, privacy, or just to escape the corporate BS. We're the people who choose the harder path when we think it's worth it.

Which is why I find it so damn interesting that atomic distros haven't caught on more. The landscape is incredibly diverse now - from gaming-focused Bazzite to the purely functional philosophy of Guix System. These distros couldn't be more different in their approaches, but they all share this core atomic DNA.

These systems offer some seriously compelling stuff - updates that either work 100% or roll back automatically, no more "oops I bricked my system" moments, better security through immutability, and way fewer update headaches.

So what gives? Why aren't more of us jumping on board? From my conversations and personal experience, I think it boils down to a few things:

Our current setups already work fine. Let's be honest - when you've spent years perfecting your Arch or Debian setup, the thought of learning a whole new paradigm feels exhausting. Why fix what isn't broken, right?

The learning curve seems steep. Yes, you can do pretty much everything on atomic distros that you can on traditional ones, but the how is different. Instead of apt install whatever and editing config files directly, you're suddenly dealing with containers, layering, or declarative configs. It's not necessarily harder, just... different.

The docs can be sparse. Traditional distros have decades of guides, forum posts, and StackExchange answers. Atomic systems? Not nearly as much. When something breaks at 2am, knowing there's a million Google results for your error message is comforting.

I've been thinking about this because Linux has overcome similar hurdles before. Remember when gaming on Linux was basically impossible? Now we have the Steam Deck running an immutable SteamOS (of all things!) and my non-Linux friends are buying them without even realizing they're using Linux. It just works.

So I'm genuinely curious - what's keeping YOU from switching to an atomic distro? Is it specific software you need? Concerns about customization? Just can't be bothered to learn new tricks?

Your answers might actually help developers focus on the right pain points. The atomic approach makes so much sense on paper that I'm convinced it's the future - we just need to figure out what's stopping people from making the jump today.

So what would it actually take to get you to switch? I'm all ears.

 

Look, I've only been a Linux user for a couple of years, but if there's one thing I've learned, it's that we're not afraid to tinker. Most of us came from Windows or macOS at some point, ditching the mainstream for better control, privacy, or just to escape the corporate BS. We're the people who choose the harder path when we think it's worth it.

Which is why I find it so damn interesting that atomic distros haven't caught on more. The landscape is incredibly diverse now - from gaming-focused Bazzite to the purely functional philosophy of Guix System. These distros couldn't be more different in their approaches, but they all share this core atomic DNA.

These systems offer some seriously compelling stuff - updates that either work 100% or roll back automatically, no more "oops I bricked my system" moments, better security through immutability, and way fewer update headaches.

So what gives? Why aren't more of us jumping on board? From my conversations and personal experience, I think it boils down to a few things:

Our current setups already work fine. Let's be honest - when you've spent years perfecting your Arch or Debian setup, the thought of learning a whole new paradigm feels exhausting. Why fix what isn't broken, right?

The learning curve seems steep. Yes, you can do pretty much everything on atomic distros that you can on traditional ones, but the how is different. Instead of apt install whatever and editing config files directly, you're suddenly dealing with containers, layering, or declarative configs. It's not necessarily harder, just... different.

The docs can be sparse. Traditional distros have decades of guides, forum posts, and StackExchange answers. Atomic systems? Not nearly as much. When something breaks at 2am, knowing there's a million Google results for your error message is comforting.

I've been thinking about this because Linux has overcome similar hurdles before. Remember when gaming on Linux was basically impossible? Now we have the Steam Deck running an immutable SteamOS (of all things!) and my non-Linux friends are buying them without even realizing they're using Linux. It just works.

So I'm genuinely curious - what's keeping YOU from switching to an atomic distro? Is it specific software you need? Concerns about customization? Just can't be bothered to learn new tricks?

Your answers might actually help developers focus on the right pain points. The atomic approach makes so much sense on paper that I'm convinced it's the future - we just need to figure out what's stopping people from making the jump today.

So what would it actually take to get you to switch? I'm all ears.

 

Look, I've only been a Linux user for a couple of years, but if there's one thing I've learned, it's that we're not afraid to tinker. Most of us came from Windows or macOS at some point, ditching the mainstream for better control, privacy, or just to escape the corporate BS. We're the people who choose the harder path when we think it's worth it.

Which is why I find it so damn interesting that atomic distros haven't caught on more. The landscape is incredibly diverse now - from gaming-focused Bazzite to the purely functional philosophy of Guix System. These distros couldn't be more different in their approaches, but they all share this core atomic DNA.

These systems offer some seriously compelling stuff - updates that either work 100% or roll back automatically, no more "oops I bricked my system" moments, better security through immutability, and way fewer update headaches.

So what gives? Why aren't more of us jumping on board? From my conversations and personal experience, I think it boils down to a few things:

Our current setups already work fine. Let's be honest - when you've spent years perfecting your Arch or Debian setup, the thought of learning a whole new paradigm feels exhausting. Why fix what isn't broken, right?

The learning curve seems steep. Yes, you can do pretty much everything on atomic distros that you can on traditional ones, but the how is different. Instead of apt install whatever and editing config files directly, you're suddenly dealing with containers, layering, or declarative configs. It's not necessarily harder, just... different.

The docs can be sparse. Traditional distros have decades of guides, forum posts, and StackExchange answers. Atomic systems? Not nearly as much. When something breaks at 2am, knowing there's a million Google results for your error message is comforting.

I've been thinking about this because Linux has overcome similar hurdles before. Remember when gaming on Linux was basically impossible? Now we have the Steam Deck running an immutable SteamOS (of all things!) and my non-Linux friends are buying them without even realizing they're using Linux. It just works.

So I'm genuinely curious - what's keeping YOU from switching to an atomic distro? Is it specific software you need? Concerns about customization? Just can't be bothered to learn new tricks?

Your answers might actually help developers focus on the right pain points. The atomic approach makes so much sense on paper that I'm convinced it's the future - we just need to figure out what's stopping people from making the jump today.

So what would it actually take to get you to switch? I'm all ears.

view more: โ€น prev next โ€บ