• 0 Posts
  • 28 Comments
Joined 13 days ago
cake
Cake day: April 1st, 2026

help-circle
  • OUwUOtoLinuxMX Linux KDE appreciation post
    link
    fedilink
    arrow-up
    1
    ·
    5 days ago

    We already have container images for use with bootc of many non-Fedora distros (including Debian). This is (part of) the groundwork I alluded to earlier. So it’s definitely possible. But I agree with you: it will only happen after the people in charge are interested in solving this.

    And even if I’m being (very) optimistic, I can only see an officially supported bootc-variant of Debian come into fruition if it’s necessarily better than the alternative; kinda like how systemd replaced the default init on most distros. And, even then, I only expect it to live alongside traditional Debian. As I’m simply unsure whether all of its kinks will eventually be ironed out. Only time will tell…



  • OUwUOtoLinuxMX Linux KDE appreciation post
    link
    fedilink
    arrow-up
    1
    ·
    5 days ago

    But that’s the thing, I (and together with me many others) have already been doing this for a couple of years now. Granted, this is on another distro*. But I honestly don’t know why it wouldn’t be possible on Debian; perhaps (some of) the groundwork has already been put into place 😉.


  • OUwUOtoLinuxMX Linux KDE appreciation post
    link
    fedilink
    arrow-up
    1
    ·
    5 days ago

    The possibility of unattended major upgrades would without a doubt be an upgrade over this mess. Even if it becomes possible, it doesn’t have to be enabled by default anyways. So, if you don’t like it, then you should be able to only make use of UnattendedUpgrades for minor upgrades; if at all*.

    Besides, I don’t think the crowds that use Fedora or Ubuntu Interim are necessarily opposed to it. Especially not if it’s just seamless. Like, what would be even there to oppose if it doesn’t introduce any troubles?


  • OUwUOtoLinuxMX Linux KDE appreciation post
    link
    fedilink
    arrow-up
    2
    ·
    5 days ago

    ?

    You can easily disable or uninstall unattended upgrades, and I would definitely have noticed if Debian’s unattended upgrades automatically did major release upgrades on its own …

    To be clear, the automatic major release updates in the background does not happen on Debian. I was describing the experience on my daily driver; which happens to be another distro. That’s why I wish to see the day in which Debian does receive this. I’m aware of UnattendedUpgrades doing minor upgrades only; so no major upgrades*.

    IMO that’s not an issue at all, both Debian and Ubuntu are very good about providing security updates for their oldstable releases. Maybe your desktop environment or text editor isn’t going to receive updates anymore, but I have a really hard time imagining a relevant scenario where that makes a difference for security.

    I absolutely love the effort put in by Debian’s Security Team. But as they only provide it for three years after release, I don’t feel confident to continue using it, even if I value the work of the group of volunteers that make Debian LTS possible. Note that “too paranoid” were keywords in my previous message.


  • OUwUOtoLinuxMX Linux KDE appreciation post
    link
    fedilink
    arrow-up
    1
    ·
    5 days ago

    I did maybe half of these steps and it still went without issue.

    That’s cool and all. But, to give some context as to where I’m coming from: for the last 2-3 years or so, I receive automatic major release updates in the background. Sometimes, it takes me up to a week before I even notice it. I wish to see the day that Debian is released from its UnattendedUpgrades shackles and can ascend into pure bliss.

    I’m a big fan of skipping over one major release when upgrading

    I’m too paranoid on security to consider that 😅. But I’m glad it works out for you.




  • Thank you for that! IIRC, it was one of the settings I took from bash-sensible. I can say that it definitely improved after just a couple of changes to ~/.bashrc. Add in ble.sh and it suddenly seemed somewhat modern instead of archaic.

    Unfortunately, I don’t remember exactly what broke the camel’s back. However, FWIW, contrary to how I recall my experiences with bash and zsh, I don’t feel any frustration while using using fish. So it’s definitely doing something for me 😉.







  • As I suppose the other user already went over your main query, I’ll instead focus on what might have felt rather innocuous.

    my default shell is fish

    I subscribe to the school of thought that one should not change their default shell[1] through invoking chsh (or whatever other method that applies changes to /etc/passwd). This article does an excellent job at laying down the reasoning (and the recommended alternative). FWIW, the alternative’s day-to-day experience provides all of the pros without any of the cons.


    1. I suppose it could be fine~ish as long as it’s POSIX compliant AND compatible with bash. Which, unfortunately, fish happens to be neither of the two. ↩︎


  • fish - Ever since I’ve made the switch to Linux, the terminal has been part of the experience. And, honestly, I wouldn’t want it any other way. Besides its efficiency, I also very much enjoy how it automatically keeps track of everything I do within. I don’t get that functionality whenever I do something within a GUI. But bash left a lot to be desired in that regard; its history simply didn’t record everything. It was also pretty bare-bones; no syntax highlighting, no auto suggestions etc. Thus, after trying to bend bash (and later zsh) to my will and ultimately being dissatisfied with the janky mess I was left with, I finally gave in to at least give fish a honest try. The rest is history. Heck, fish is the very first thing I install on a machine.