Live data from Hacker News

Why is Debian the way it is?

blog.liw.fi

71–80 of 198 posts

Re: Why is Debian the way it is?

#71
post #3

Well certainly part of it is much of the .deb ecosystem still feels like its stuck in the late 90s linux era to me. But maybe I'm alone on that gut feel.

I'd like you to explain this a bit deeper. As a user from the '90s I am quite happy with it, but I might be stuck in my ways, who knows? So not saying you're wrong, but what are we missing exactly?

what deb and rpm and any similar packaging are missing is true version control of the whole packaging ecosystem. at present it is difficult to track which combination of package versions has been tested, and you can't easily roll back to a tested combination. the current systems assume that versioning is linear and that a newer version of any package is always better than an older version. downgrading any package so that every user of the distribution can benefit from the downgrade is difficult and confusing.

there are distributions that provide rollback. but as far as i can tell they require you to keep the old version to roll back to, stored on your computer. you can't roll back otherwise.

i really want this to work like revision systems for code, where i can just checkout any old version that was committed.

another feature that i would like to see everywhere is stickiness of the packaging source. currently, if i include additional repos they override the main repo, such that always the newest version is picked from any repo.

this makes it difficult to include less trusted 3rd party repos. i would like to be able to add 3rd party repos such that only the packages that i explicitly install from that repo will also be updated from that repo, while any other packages in that repo will be ignored unless no other repo has them.

in debian it is possible to set priorities for different repos, but that is not easy to manage. the priorities to have each package update stick to the original repo should be default.

guix and nix do provide some of this as far as i can tell, but i am not a fan of keeping every package self contained with massive link trees. (i may change my mind on that some time maybe, but that's what i feel for now)

conary was/(is?) a packaging system that did have both of these features, although, according to some of the developers the repository was a bit clunky and could have been better. but that was under the hood, not noticeable to users and packagers. i loved working with it and i wish foresight, the distribution using it had become more popular so that it would have had the manpower to keep going.

Re: Why is Debian the way it is?

#72

Earlier quoted context omitted.

Yeah, I agree. Systemd is incredibly controversial among a niche group of people who have strong opinions about how init & core system functionality should work, and then there’s an outer ring of people who focus on one or two problems with some relatively minor problems that Systemd caused for which there are viable workarounds. Like how Systemd terminates processes that belong to your session when you log out. I re…

Have you looked at OpenBSD? Here's the /etc/rc.d/sshd: #!/bin/ksh # # $OpenBSD: sshd,v 1.7 2022/08/29 19:14:25 ajacoutot Exp $ daemon="/usr/sbin/sshd" . /etc/rc.d/rc.subr pexp="sshd: ${daemon}${daemon_flags:+ ${daemon_flags}} \[listener\].*" rc_configtest() { ${daemon} ${daemon_flags} -t } rc_cmd $1 Pretty much any service/daemon is similar. You define a few things and you're done.

A declarative unit file is still more readable for me.

Re: Why is Debian the way it is?

#73

Earlier quoted context omitted.

They've now relaxed their (stupid) policy so at least the default ISO includes non-free drivers. When it comes to an already installed system, enabling the non-free repos and installing linux-firmware (or more specific firmware-* package for your hardware) should fix it.

If the default ISO already included non-free drivers, why would you have to separately enable the non-free repos to get firmware? My Debian 12 install didn't come with proprietary Nvidia drivers, nor did it ask me if I wanted them during installation. I had to enable the non-free-firmware repo to get them.

> If the default ISO already included non-free drivers, why would you have to separately enable the non-free repos to get firmware?

I'm not 100% sure about this but I believe it may enable it for you automatically if non-free firmware was used during the install. I mentioned it just in case.

> My Debian 12 install didn't come with proprietary Nvidia drivers

The primary problem of the previous non-free driver policy is the lack of network drivers which make it impossible to install nor download the drivers even if you somehow managed to install the OS. This is now resolved.

It's not a big deal if the ISO doesn't include every non-free driver out there as long as you can manually install it after the fact.

Re: Why is Debian the way it is?

#74

I worked with Ian Murdock at Purdue in the days of the very first release. He was a sysadmin and devloper while I was a web designer for the libraries. The guy truly believed in the GNU/Linux 'way' and 'free as in speech' software. His initial drive was from the difficulty of packaging and package management and that is probably his biggest contribution. Network-of-Workstations (NOW... think peer-to-peer infratsructu…

[deleted]

Re: Why is Debian the way it is?

#75
post #67

Debian's policies also led to a heavily restricted version of RetroArch being available instead of the real version. Specifically, RetroArch has its own package management functionality built-in through its "Core Updater" feature, which downloads and installs emulators in the form of library files. This is banned by Debian because it sidesteps the whole package manager system. Meanwhile, you can still build the full…

Debian is somewhat of a bad fit for a media center PC. I've learned that the hard way trying to get Kodi and retro arch working.

It's otherwise a great os.

Re: Why is Debian the way it is?

#76

Earlier quoted context omitted.

Yeah, I agree. Systemd is incredibly controversial among a niche group of people who have strong opinions about how init & core system functionality should work, and then there’s an outer ring of people who focus on one or two problems with some relatively minor problems that Systemd caused for which there are viable workarounds. Like how Systemd terminates processes that belong to your session when you log out. I re…

Have you looked at OpenBSD? Here's the /etc/rc.d/sshd: #!/bin/ksh # # $OpenBSD: sshd,v 1.7 2022/08/29 19:14:25 ajacoutot Exp $ daemon="/usr/sbin/sshd" . /etc/rc.d/rc.subr pexp="sshd: ${daemon}${daemon_flags:+ ${daemon_flags}} \[listener\].*" rc_configtest() { ${daemon} ${daemon_flags} -t } rc_cmd $1 Pretty much any service/daemon is similar. You define a few things and you're done.

Why in the world korn shell?

I stumbled upon an auditor with programming skills, who did all his scripting in Korn shell. To me it was like he was from another planet.

Re: Why is Debian the way it is?

#77
post #67

Debian's policies also led to a heavily restricted version of RetroArch being available instead of the real version. Specifically, RetroArch has its own package management functionality built-in through its "Core Updater" feature, which downloads and installs emulators in the form of library files. This is banned by Debian because it sidesteps the whole package manager system. Meanwhile, you can still build the full…

RetroArch provides a Flatpak, making this mostly a non-issue.

Re: Why is Debian the way it is?

#79

Earlier quoted context omitted.

Yeah, I agree. Systemd is incredibly controversial among a niche group of people who have strong opinions about how init & core system functionality should work, and then there’s an outer ring of people who focus on one or two problems with some relatively minor problems that Systemd caused for which there are viable workarounds. Like how Systemd terminates processes that belong to your session when you log out. I re…

Have you looked at OpenBSD? Here's the /etc/rc.d/sshd: #!/bin/ksh # # $OpenBSD: sshd,v 1.7 2022/08/29 19:14:25 ajacoutot Exp $ daemon="/usr/sbin/sshd" . /etc/rc.d/rc.subr pexp="sshd: ${daemon}${daemon_flags:+ ${daemon_flags}} \[listener\].*" rc_configtest() { ${daemon} ${daemon_flags} -t } rc_cmd $1 Pretty much any service/daemon is similar. You define a few things and you're done.

Here is the systemd unit for comparison:

  [Unit]
  Description=OpenBSD Secure Shell server per-connection daemon
  After=auditd.service

  [Service]
  EnvironmentFile=/etc/default/ssh
  ExecStart=/usr/sbin/sshd -i $SSHD_OPTS
  StandardInput=socket
I leave it to the reader to decide which of those two is easier to understand and maintain.

Re: Why is Debian the way it is?

#80
post #17

[flagged]

I think it was why they got on the systemD train. It was the init system they thought they could maintain well. Sounds like there were lots of hurt feeling in the whole situation. Did some major Debian maintainers actually leave Debian for Devuan? If Devuan’s contributors were originally just Debian users, it seems like no loss for Debian and a win for the community (more developers).

They could have permitted volunteers to maintain sysv or openrc versions of init scripts and made it an installer option. I believe devs and users alike were part of the devuan fork: https://www.devuan.org/os/announce/
Post reply on HN