Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

20 years as a Debian maintainer

suihkulokki.blogspot.com

Post reply on HN
Print view View original

81–90 of 126 posts

Re: 20 years as a Debian maintainer

#81

Post by steveklabnik »

dromen wrote: post #77
davexunit wrote: post #51

Earlier quoted context omitted.

There's no easy road. We need to convince upstream to change their ways. The proliferation of language-specific package managers is a problem that many people don't yet understand is a problem. I often get hostile reactions when I advocate for general-purpose systems package managers over language-specific ones. In the meantime, we can use the information available in these language package managers to help bring tha…

I watched the Rust packaging effort via the mailing list, and that seems to be going quite well. Would you happen to know a good video or writeup on why language-specific package managers are a bad idea? I mean, the situation with C and C++ libraries seems significantly worse to me, and I personally really enjoy having the fully Crates.io index at my disposal on any box that runs Cargo.

Not your parent, but I personally believe that using "package managers" to describe both of these things conflates the issue. That is, both are valuable, for different reasons. The shortest way that I can describe it is this: I use my system package manager to install things for software that I'm not developing, but language-specific managers for software that I am actively developing. When I used to write a lot of Ruby, I had my own install, but now that I mostly write Rust, I have Ruby installed via apt-get.

The two styles of managers just have different goals. That is, a package manager such as apt has the goal of creating a single, harmonious system from stuff written in many languages. But a language-specific package manager like Cargo has the opposite goal: to provide a good way of writing software written in one language across multiple systems. This is where most of the tension comes from. The rest of it is from the same general structure, but with different specifics: the goals of these kinds of systems are very different, and conflicting.

Software is hard.

Re: 20 years as a Debian maintainer

#82

Post by Z-Widwil »

barrkel wrote: post #57
Z-Widwil wrote: post #50

Earlier quoted context omitted.

Having just set up a Debian server this weekend (Windows dev diving into Linux for the first time), can I ask what the main difference between init and systemd are? Mostly from a operational/security stand point.

Init-scripts are a bunch of file system conventions and shell scripts; it's an imperative way of bringing a system into a particular state (networking, services etc.). Init itself is the very first process the the OS executes; all processes in -nix are created by forking. When using init-scripts, init is extremely simple. Systemd replaces init and uses a declarative approach for the system and its services, and the d…

Thank you for the informative and neutral response. I knew there was a larger debate over the two, but I didn't have a good enough understanding of the two to know why.

Re: 20 years as a Debian maintainer

#83

Post by voltagex_ »

irl_ wrote: post #16
deadbunny wrote: post #9

Earlier quoted context omitted.

If they can't make good packages then I can't see them making good containers.

As a Debian Developer I often find myself throwing away the upstream Debian packaging and starting from scratch. It's not that it doesn't work but that it doesn't fit with Debian policy and so is not easily included or modified without basically starting from scratch anyway. In the cases (which happens more than you might think) where an upstream developer has actually got really good packaging, I've usually taken th…

If I've got a project on GitHub, should I have a debian/ directory in there? Where does git-buildpackage fit in?

Re: 20 years as a Debian maintainer

#84

Post by elsurudo »

cixin wrote: post #3

In case the author reads this, and as I can't comment there: Thank you. Debian is an awesome and somewhat under-rated distribution. Being a maintainer always seems like a thankless and slightly forgotten role. Thanks for having the persistence to keep going so long.

Is it under-rated? Perhaps its marketing isn't as strong, but it's the "father" of a lot of distros today. Personally when I want a server distro, I still go with Debian. Simple and solid. No nonsense.

Re: 20 years as a Debian maintainer

#85

Post by zer0t3ch »

SteveNuts wrote: post #41
icebraining wrote: post #39

Earlier quoted context omitted.

I'm not rxlim, but considering that the release after Wheezy - Jessie - introduced systemd as the default init systemd, it's not hard to guess.

I went into systemd with an open mind, hoping the changes would be worthwhile to learn. I've come out the other end looking for alternatives... In the meantime I'll stick to an OS that uses init, and hope systemd get's better given enough time.

As someone who basically started getting into Linux with Systemd (I had dabbled before, but not in-depth) I love it. Mind expanding on what you don't like about it?

One thing I do remember before Systemd though was the fact that every service was essentially a glorified bash script, and I hated that. With Systemd, there seems to generally be a much more clear-cut definition of how things operate, without all the cruft.

Re: 20 years as a Debian maintainer

#86

Post by zer0t3ch »

digler999 wrote: post #76
Z-Widwil wrote: post #50

Earlier quoted context omitted.

Having just set up a Debian server this weekend (Windows dev diving into Linux for the first time), can I ask what the main difference between init and systemd are? Mostly from a operational/security stand point.

without realizing it you casually strolled into one of the biggest points of contention and controversy in computing history. Systemd came out a few years ago, and wars were fought over it. It fixes a lot of bugs that perennially came up with run scripts, but it's also a huge monolithic program that is in charge of nearly everything on your system. That's about all I'll say on it, because it's almost as divisive as t…

> it's almost as divisive as the Israel/Palestine conflict

But who doesn't love a good bit of conflict, amirite?

Re: 20 years as a Debian maintainer

#87

Post by JdeBP »

Z-Widwil wrote: post #82
barrkel wrote: post #57

Earlier quoted context omitted.

Init-scripts are a bunch of file system conventions and shell scripts; it's an imperative way of bringing a system into a particular state (networking, services etc.). Init itself is the very first process the the OS executes; all processes in -nix are created by forking. When using init-scripts, init is extremely simple. Systemd replaces init and uses a declarative approach for the system and its services, and the d…

Thank you for the informative and neutral response. I knew there was a larger debate over the two, but I didn't have a good enough understanding of the two to know why.

You still have not. (-:

barrkel talked about systemd as a replacement for init, but that's not the goal of its authors. Nor was there a debate over the two.

There was a debate in Debian Land over at least four choices: systemd, upstart, OpenRC, and sticking with van Smoorenburg rc with Debian's various enhancements.

The stated goal of the systemd authors pretty much from the start was not to "replace init", or even to replace both init and rc. What barrkel wrote could be said of daemontools from 1997, after all. That, too, encouraged a move of common procedures and mechanisms out of bespoke daemon programs and scripts and into a common daemon management system.

systemd, rather, was to provide a common layer, beneath everything else and above the kernel, used on all Linux operating systems. Its authors saw the differences such as /etc/sysconfig/network versus /etc/HOSTNAME versus /etc/hostname versus /etc/conf.d/hostname and wanted to unify all that, so that all Linux distributions worked the same. They didn't just write process #1 program. They wrote a name-lookup server with a local protocol to replace the DNS protocol (and the protocol that GNU libc uses to talk to its lookup helper processes), a network interface setup/teardown utility, a whole bunch of service utility programs such as a program to save/restore randomness from /dev/urandom across system restart, a centralized log writer, a centralized login session manager, and a whole bunch of programs that provided RPC interfaces, over a centralized system-wide Desktop Bus instance to GUI tools running on user/administrator GUI desktops, for things like setting the default timezone and pretty-print hostname. To that they added rules about where to find different sorts of stuff, from administrator-written unit files to /etc/machine-id; guarantees about "API filesystems"; rules about /run, /run/user, and a whole bunch of related memory filesystems; deprecation of things like /var/run/lock; rules about what sockets old syslog programs had to change to using, in place of what they had been; per-user service manager instances and a whole extra set of PAM hooks that connected it with the new runtime directories and the login session manager; and requirements such as that /usr be already available at the point that /sbin/init is invoked from the initramfs. They got some additions made to Linux in support of this, such as subreapers; and failed to get others, such as kdbus.

"systemd replaces init" is both superficial and a blinkered Debian world-view. In the world outwith Debian, in Ubuntu Land and Fedora Land, systemd replaced upstart, which had been the Fedora and Ubuntu system and service manager for a number of years before systemd was invented. The world has never been van Smoorenburg rc scripts versus systemd, not even when the whole Debian debate was had.

* http://jdebp.eu./FGA/debian-systemd-packaging-hoo-hah.html

* http://blog.darknedgy.net/technology/2015/09/05/0/

* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/

Re: 20 years as a Debian maintainer

#88

Post by new299 »

elsurudo wrote: post #84
cixin wrote: post #3

In case the author reads this, and as I can't comment there: Thank you. Debian is an awesome and somewhat under-rated distribution. Being a maintainer always seems like a thankless and slightly forgotten role. Thanks for having the persistence to keep going so long.

Is it under-rated? Perhaps its marketing isn't as strong, but it's the "father" of a lot of distros today. Personally when I want a server distro, I still go with Debian. Simple and solid. No nonsense.

Personally, I feel like Ubuntu gets a lot more attention, perhaps more on the client-side. Sometimes, the foundational work Debian provides isn't fully acknowledged.

Re: 20 years as a Debian maintainer

#89

Post by JdeBP »

jcrites wrote: post #61
barrkel wrote: post #57

Earlier quoted context omitted.

Init-scripts are a bunch of file system conventions and shell scripts; it's an imperative way of bringing a system into a particular state (networking, services etc.). Init itself is the very first process the the OS executes; all processes in -nix are created by forking. When using init-scripts, init is extremely simple. Systemd replaces init and uses a declarative approach for the system and its services, and the d…

One of the most informative writings I've read on the topic of systemd and its benefits and comparison with other tools was written by Russ Allbery, which explains his contribution to Debian's choice to adopt it [1]: > I did a fairly extensive evaluation of both upstart and systemd by converting one of my packages[] to a native configuration with both systems. []I tried to approach each init system on its own terms a…

It is an interesting contrast with the Arch decision process that occurred.

* https://news.ycombinator.com/item?id=11834348

Re: 20 years as a Debian maintainer

#90

Post by BuuQu9hu »

radarsat1 wrote: post #40
BuuQu9hu wrote: post #21

Earlier quoted context omitted.

It can be easy for certain kinds of software: https://wiki.debian.org/AutomaticPackagingTools https://manpages.debian.org/man/1/dh_auto_configure https://manpages.debian.org/man/1/dh_auto_build https://manpages.debian.org/man/1/dh_auto_install

What I find complicated about Debian packaging is not how to use the tools and how to arrange the package, although that is certainly complicated, but not intractable. What I don't understand is once you have a package, why it is such a long and complicated process to get it into Debian. You can't just upload it and forget, you have to sign up and become associated with that work, you have distribute your keys and ge…

These days there are several very active sponsors so it should not be a problem to get new packages in.

Upload and forget leads to dead packages that get removed next time there is a library transition. Debian is about long-term maintenance.

The social stuff (as well as the social contract and DFSG) is also what creates trust within and towards the Debian community and holds it together, which is the main reason it has lasted so long.

Post reply on HN