4 ms·

Yeah. I keep coming back to Debian after trying out another distro for a while. There are some specific complaints I have about technical choices for Debian, l

Yeah. I keep coming back to Debian after trying out another distro for a while. There are some specific complaints I have about technical choices for Debian, like the way daemons autostart post install. But these complaints are outweighed by the benefits of using a distro with coherence across packages and upgrades. Apt is also just such a phenomenal package manager. It is fast out of the box, and supports some relatively tricky scenarios—like using stable for your system, but a newer Nginx from backports. Feels like I can get the newer features for the one or two packages that I really care about, and then use something stable and boring for everything else.

chubot 3y ago
Yup exactly, I hated the daemon autostart thing. But it's a small issue compared to the mess I see in the rest of software these days ... Alpine Linux seems interesting too, although right now Debian suits me well. I guess the problem is that I still don't make Debian packages myself, while Alpine's APKBUILD seems more approachable -- pure shell, while Debian has an array of tools and formats. But Debian "lagging" a bit can be a feature, not necessarily a bug.
bostik 3y ago
I'm a Debian user since 1998 and have had it as my personal desktop since that time. I'd think that counts for something. > Apt is also just such a phenomenal package manager. It is fast out of the box, This wasn't always the case. There's a good reason almost all guides first written before 2015 specifically instructed everyone to use 'apt-get' directly. For quite some time the more uniform 'apt' frontend really wasn't intuitive or helpful. (Just to be clear: these days it is phenomenal in its simplicity and clarity.) And as someone who has has to dive in to the package managers' code bases, the overall quality of libapt used to be .. questionable. Figuring out code and control flows back in 2010 was like trying to rub chili out of your eyes with an unsanded wooden spoon. But the sheer bullheaded stubbornness Debian imposes on their package universe and its architecture means it's an absolute joy to work with if you're doing any kind of distro customisation work.
- natebc 3y ago
  FWIW the current recommendation is still to use apt-get in your scripts. It's less about stability and more about intention for backwards compatibility. Perfectly fine to use apt interactively, it is as you say phenominal, simple and clear. from apt(8): SCRIPT USAGE AND DIFFERENCES FROM OTHER APT TOOLS The apt(8) commandline is designed as an end-user tool and it may change behavior between versions. While it tries not to break backward compatibility this is not guaranteed either if a change seems beneficial for interactive use. All features of apt(8) are available in dedicated APT tools like apt-get(8) and apt-cache(8) as well. apt(8) just changes the default value of some options (see apt.conf(5) and specifically the Binary scope). So you should prefer using these commands (potentially with some additional options enabled) in your scripts as they keep backward compatibility as much as possible. https://manpages.debian.org/bookworm/apt/apt.8.en.html#SCRIPT_USAGE_AND_DIFFERENCES_FROM_OTHER_APT_TOOLS https://manpages.debian.org/bookworm/apt/apt.8.en.html#SCRIP...
- pwdisswordfishc 3y ago
  For quite some time the more uniform 'apt' frontend really didn't exist at all.
  - jwilk 3y ago
    Indeed. The "apt" frontend was added in 2014 and included in a stable release in 2015. So I don't know what tool other than apt-get could "guides first written before 2015" use.
    - colanderman 3y ago
      aptitude. And before that, dselect (which I believe predated APT entirely).
      - cassianoleal 3y ago
        Oh my, I don't miss the dselect days. OTOH aptitude is, to this day, a joy to use.
kefyras 3y ago
> like the way daemons autostart post install This can be configured with service-policy.d(5), see https://packages.debian.org/bookworm/policy-rcd-declarative-deny-all https://packages.debian.org/bookworm/policy-rcd-declarative-... for example.

chubot 3y ago

Yup exactly, I hated the daemon autostart thing. But it's a small issue compared to the mess I see in the rest of software these days ... Alpine Linux seems interesting too, although right now Debian suits me well. I guess the problem is that I still don't make Debian packages myself, while Alpine's APKBUILD seems more approachable -- pure shell, while Debian has an array of tools and formats. But Debian "lagging" a bit can be a feature, not necessarily a bug.

bostik 3y ago

I'm a Debian user since 1998 and have had it as my personal desktop since that time. I'd think that counts for something. > Apt is also just such a phenomenal package manager. It is fast out of the box, This wasn't always the case. There's a good reason almost all guides first written before 2015 specifically instructed everyone to use 'apt-get' directly. For quite some time the more uniform 'apt' frontend really wasn't intuitive or helpful. (Just to be clear: these days it is phenomenal in its simplicity and clarity.) And as someone who has has to dive in to the package managers' code bases, the overall quality of libapt used to be .. questionable. Figuring out code and control flows back in 2010 was like trying to rub chili out of your eyes with an unsanded wooden spoon. But the sheer bullheaded stubbornness Debian imposes on their package universe and its architecture means it's an absolute joy to work with if you're doing any kind of distro customisation work.

natebc 3y ago
FWIW the current recommendation is still to use apt-get in your scripts. It's less about stability and more about intention for backwards compatibility. Perfectly fine to use apt interactively, it is as you say phenominal, simple and clear. from apt(8): SCRIPT USAGE AND DIFFERENCES FROM OTHER APT TOOLS The apt(8) commandline is designed as an end-user tool and it may change behavior between versions. While it tries not to break backward compatibility this is not guaranteed either if a change seems beneficial for interactive use. All features of apt(8) are available in dedicated APT tools like apt-get(8) and apt-cache(8) as well. apt(8) just changes the default value of some options (see apt.conf(5) and specifically the Binary scope). So you should prefer using these commands (potentially with some additional options enabled) in your scripts as they keep backward compatibility as much as possible. https://manpages.debian.org/bookworm/apt/apt.8.en.html#SCRIPT_USAGE_AND_DIFFERENCES_FROM_OTHER_APT_TOOLS https://manpages.debian.org/bookworm/apt/apt.8.en.html#SCRIP...
pwdisswordfishc 3y ago
For quite some time the more uniform 'apt' frontend really didn't exist at all.
- jwilk 3y ago
  Indeed. The "apt" frontend was added in 2014 and included in a stable release in 2015. So I don't know what tool other than apt-get could "guides first written before 2015" use.
  - colanderman 3y ago
    aptitude. And before that, dselect (which I believe predated APT entirely).
    - cassianoleal 3y ago
      Oh my, I don't miss the dselect days. OTOH aptitude is, to this day, a joy to use.

kefyras 3y ago

> like the way daemons autostart post install This can be configured with service-policy.d(5), see https://packages.debian.org/bookworm/policy-rcd-declarative-deny-all https://packages.debian.org/bookworm/policy-rcd-declarative-... for example.