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

101–110 of 126 posts

Re: 20 years as a Debian maintainer

#101

Post by davexunit »

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.

I think language-specific package managers are just fine for sharing source code for that language with other developers of that language. But as soon as you need to do more than that they become extremely problematic. The dependency tree for a Crate (or a package in any other similar system) ends where the Rust dependencies end. It cannot describe the full dependency graph for any package that depends on a program or library written in another language. I'm more familiar with Ruby so here's a real-life example: The mysql2 gem needs to compile a C extension and link against libmysqlclient. However, the 'gem' utility only handles Ruby dependencies, so in order to 'gem install mysql2' you need to use your system package manager to provide 'libmysqlclient'. There's always going to be this disconnect and you'll have to use multiple package managers in order to get anything working. It's very error prone. Wouldn't be great if a single packager manager could describe the complete dependency graph? This is a big reason why I advocate for GNU Guix. I do devops for a living, and much of the difficulties I face are due to problems trying to glue multiple package managers together.

Re: 20 years as a Debian maintainer

#102

Post by davexunit »

steveklabnik wrote: post #100
davexunit wrote: post #98

Earlier quoted context omitted.

There's no need for two styles of package managers. GNU Guix and Nix can serve both purposes (and more) very well, for example. I think language-specific package managers are fine for easily sharing source code amongst developers using the same language, but they shouldn't be used in a production system.

I don't necessarily disagree. I think your third sentence still implies two styles, which is contradicting your first. Nix and Guix don't work on Windows, right? They're still not close to a solution until they do.

If you're on Windows, then fine use whatever is available. A language specific package manager is about as good as it gets there. There are no good package managers for Windows, and I don't think there can be. I don't even know if you can isolate builds in a container like you can on GNU/Linux. That's a crucial OS feature. Besides, I aim to liberate users, not enslave them, so I develop for the GNU system, not Windows.

The third sentence is not a contradiction. I'm just saying that I can live with people using language-specific package managers, but really they would be better off with a general-purpose one.

Re: 20 years as a Debian maintainer

#103

Post by BuuQu9hu »

saghm wrote: post #97
zer0t3ch wrote: post #85

Earlier quoted context omitted.

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

One of the big issues a lot of people have (or at least had, back when it was first becoming a thing) was that systemd uses binary log files rather than traditional text ones, which makes them harder to deal with (e.g. you can't `tail` or `grep` them, at least not directly). Another common gripe is that while it started out as an init system, a rather large portion of userland on a typical system depends on one or mo…

tail: journalctl -f

Personally, I found journalctl much better than text based logs.

For the timeouts, I think try the systemd-bootchart thing.

Re: 20 years as a Debian maintainer

#104

Post by brazzledazzle »

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.

I think Debian and its children are so much nicer to use from a server perspective. RHEL and its derivatives have definitely improved over the years but it seemed like Debian had the right idea early on. Things like how they managed Apache modules and an out of the box emphasis on 'conf.d'-style configuration directories are just a couple of things that come to mind. The modular thinking lends itself well to learning because changes are easy to back out and automation because it's easier to compose configuration.

Re: 20 years as a Debian maintainer

#105

Post by totony »

saghm wrote: post #97
zer0t3ch wrote: post #85

Earlier quoted context omitted.

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

One of the big issues a lot of people have (or at least had, back when it was first becoming a thing) was that systemd uses binary log files rather than traditional text ones, which makes them harder to deal with (e.g. you can't `tail` or `grep` them, at least not directly). Another common gripe is that while it started out as an init system, a rather large portion of userland on a typical system depends on one or mo…

Apparently you can use "strings /run/journal/..."

But journald lacks way more than simple text files. I tried to "mute" a process and redirect output to a file, because it was counting in the maximum journal size, and found it to be impossible "by design". Had to use an actually good log daemon, but it seems quite hard to just disable journald and not lose any log.

Re: 20 years as a Debian maintainer

#106

Post by [deleted] »

davexunit wrote: post #102
steveklabnik wrote: post #100

Earlier quoted context omitted.

I don't necessarily disagree. I think your third sentence still implies two styles, which is contradicting your first. Nix and Guix don't work on Windows, right? They're still not close to a solution until they do.

If you're on Windows, then fine use whatever is available. A language specific package manager is about as good as it gets there. There are no good package managers for Windows, and I don't think there can be. I don't even know if you can isolate builds in a container like you can on GNU/Linux. That's a crucial OS feature. Besides, I aim to liberate users, not enslave them, so I develop for the GNU system, not Window…

[deleted]

Re: 20 years as a Debian maintainer

#107

Post by flukus »

BuuQu9hu wrote: post #95
jancsika wrote: post #59

Earlier quoted context omitted.

> - Don't bundle third-party dependencies. For security (and for better documentation of the true dependency graph) distros often must go through extra trouble to unbundle third-party libraries when present. Some project even add their own custom patches to their bundled source. Resist the urge to do this. If any of the dependencies aren't currently packaged in Debian, how would one follow this guideline?

In addition to what rleigh said, you could package them for Debian :) https://mentors.debian.net/intro-maintainers

The amount of documentation there suggests it's not so easy. Especially when you're trying to get something unrelated done.

Re: 20 years as a Debian maintainer

#108

Post by lisivka »

davexunit wrote: post #99
lisivka wrote: post #73

Earlier quoted context omitted.

CPAN packages can be translated into perl packages automatically in many cases, or with little modifications. Same for python, ruby and node packages. See fpm[1] for example of one of such tools. [1]: https://www.digitalocean.com/community/tutorials/how-to-use-...

fpm is a bad example. Sure, it makes .deb or .rpm formatted things, but they are not proper packages by any means. Bundling up something pre-built from another packaging system is not what packaging is about. To do it right you need to build your own binaries from source code using only your own packages to provide the dependencies.

Of course, automatic translation of binary packages is bad thing which will produce wrong result in lot of cases, but automatic translation of source packages, with build instructions and meta-information, is time saver. For RPM, I will have a .spec file, which I then can edit further, or use tool options to fill fields with proper values. When .spec is ready, in most cases I will need to update version and changelog only to upgrade to newer version.

Re: 20 years as a Debian maintainer

#109

Post by flukus »

davexunit wrote: post #22
bostand wrote: post #10

Earlier quoted context omitted.

Sorry, I meant to write AppImage not flatpak. The point was that a lot of packaging would be done by the devs, allowing minutes maintainers to so more important stuff.

I don't think having developers doing the packaging is an ideal situation. I often hear developers complaining about the multitude of GNU/Linux distros because they think it's somehow their responsibility to provide binaries. It's not. The role of the upstream developer is to make their build system easy to use so that other people (like distro maintainers, but also just "regular" users) can compile from source witho…

> I don't think having developers doing the packaging is an ideal situation. I often hear developers complaining about the multitude of GNU/Linux distros because they think it's somehow their responsibility to provide binaries.

It is in many scenarios. If I have a little app I want to package then it becomes my responsibility. For commercial software I make it always is and this is part of the reason that linux sucks for commercial software.

And then there's issues like security patches. Developers need to know what branches are used downstream.

Re: 20 years as a Debian maintainer

#110

Post by nerflad »

gkya wrote: post #47
rxlim wrote: post #32

Earlier quoted context omitted.

FreeBSD, so the migration is not just away from Debian but also Linux. Of course problems always arise in such operations, but in general we have been very happy with the change, and I'm just as excited about FreeBSD as I was with Debian before.

Do you migrate you workstation to FreeBSD too, or your servers and the like only? In any case I want to take this opportunity to note that FreeBSD is quite nice as a daily driver on your workstation. The only missing thing is bug-free suspend/hibernate, which works for some and for some doesn't. edit: added missing adverbs.

In my experience, you're also rolling the dice when you suspend Linux. My x99 workstation, z77 workstation, and XPS 13 have all failed to resume before. But Windows has done the same. I guess ACPI is a mess.
Post reply on HN