Live data from Hacker News

Why is Debian the way it is?

blog.liw.fi

81–90 of 198 posts

Re: Why is Debian the way it is?

#81
post #45
post #35

Sometimes I daydream about getting a fuck-it amount of money. During this thought process I always make a plan of what open source software project I should donate, and debian is always one of the first several candidates. Now I just need the money! (meanwhile I donate to debian anyway)

This article from 2020 says Debian doesn't need money: https://www.theregister.com/2020/09/10/debian_project_addres...

Debian can't really directly pay contributors (there are some rare few cases like lawyers, etc....), so that would be one of the reasons for what the article is talking about.

The best thing someone could do in this scenario would to be hire someone to work on/improve Debian directly.

Re: Why is Debian the way it is?

#82

Earlier quoted context omitted.

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.

It's the standard shell on OpenBSD.

Re: Why is Debian the way it is?

#83
post #53

Earlier quoted context omitted.

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 relat…

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 was…

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#SCRIP...

Re: Why is Debian the way it is?

#84

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…

Can someone explain the controversy surrounding Bruce Perens? I never heard the story and Google isn't being helpful.

Re: Why is Debian the way it is?

#85
post #79

Earlier quoted context omitted.

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.

Debatable, but I was mainly reacting to "... rc.d / BSD style init scripts. It was awful. You had all these copy-pasted shell scripts with various gaps in functionality depending on who wrote them."

Simply not true in (modern) BSDs, well at least OpenBSD; I'm not familiar with the others.

Re: Why is Debian the way it is?

#86
post #17

[flagged]

There's an "anti-sysv-init train"? `sysvinit` is still available in the current version of Debian, Bookworm , released less than 4 months ago: https://tracker.debian.org/pkg/sysvinit Note that `runit` is also available: https://tracker.debian.org/pkg/runit Also, while it's not the default init system, there are instructions for setting it as the active init system, on the Debian wiki: https://wiki.debian.org/Init Not…

A .deb package being available is not the same as init scripts maintained or being allowed to select an init system during install.

Sysv init scripts for every package already existed since that was the only init system in use by debian until 2014, people volunteered to keep maintaining those but they were overriden in lieu if systemd only approach.

It seems you didn't use pre-systemd linux. It felt like you controlled the whole OS. Linux has always been about giving control to users. Systemd works great but it's geared towards corporate users who want better managability. So in a way, by violating the unix modularity philosophy, major distros sold out to corporations. Now systemd manages not just init but dns, logging, cron type scheduled jobs, fs mounting, system time,etc... it forced architectural changes where either you accepted systemd way or the unix way. And a lot of projects caved in.

Openrc and sysvinit manage init scripts/services. That's it. You know how they work and they are designed to be compatible with anything else. If you need a schedluled managed for example, sysvinit or openrc have no opinions how to do that, you can use cron or your own thing, you have full control. Systemd on the other hand has timers, they work great, but guess what they don't play nice with? Openrc and sysv init. Guess what plays nice with all 3? Cron and it's many implementations.

The modular design of Linux gave users power. The centralized opinionated systemd design gives the few "elite" influential people who work for big corporations power and control because their design does not take into account interoperability with arbitrary services.

Re: Why is Debian the way it is?

#87

Earlier quoted context omitted.

> Just as interesting is what happened when the corporate world decided to compete with the IETF for control of how the internet worked. Some people call this the protocol wars. ( https://en.wikipedia.org/wiki/Protocol_Wars ). For a while it seemed like each month the OSI would announce a project to replace parts of the internet, like TCP, with an X.protocol. Of these efforts very few survived and thrived - like X.50…

You are correct. A better way to put it. And it is true that the IETF working groups are often from corporate vendors. So perhaps that part of my argument is completely wrong. And distracts from the main question: could other fundamental models of collaboration be significantly more productive (efficient) than corporate models?

not entirely. I was involved in the IETF in the early 90s. At that time the old guard were the sort of second wave of internet designers (Clark, Estrin, Zhang, Cerf, Deering, Jacobsen....not going to pretend to list everyone). They primary worked off of (D)ARPA grants, although some of them them did work at places like Parc, and certainly places like Cisco.

during that time, alot more money was being dumped into this internet thing, and companies realized that if they could get their widget written into internet standards, it would be really good for business.

partially due to that, and partially due to a largely ineffective focus on multicast protocols (PIM, RSVP, etc.), these people became less central over time, and alot of the formative protocol design activity stopped.

just my perspective, but it seems odd that we're still largely stuck in the early 90s protocol-wise. clearly there have been some changes (http3, bar), but not really much considering the relative timespans.

in any case, the point being that corporate involvement in the IETF wasn't a given in the early days, and it hasn't been an unqualified win.

Re: Why is Debian the way it is?

#89
post #4

LIW left out one major chunk: because Debian is a volunteer organization, and nobody can make a volunteer do anything that they don't want to do.

From the description, the Debian organization seems to be an anarchist one. A bunch of people, not coerced to be there, have created a diffuse rotating democracy for making decisions. Self-sufficiency is key to the organization, that emerges from thoughtful usage of resources.

Re: Why is Debian the way it is?

#90
post #24

I just switched to Debian this year after ~13 years of Ubuntu, and I really appreciate it It grew on me after a long time. I always thought it was not the most "technically sound" way of doing things i.e. I don't really like the packaging model of global updates where you don't know what's going on, and sometimes there are version conflicts But I have come to appreciate the stability and good intentions of the Debian…

Same here, switched to Debian for my servers as OS from Ubuntu. Main reason: uses (boring & old) working technology. No more netplan, snapd, systemd-resolver.
Post reply on HN